finish `Reveal` removal
After #133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.
cc #132279
r? `@compiler-errors`
Rollup of 6 pull requests
Successful merges:
- #127483 (Allow disabling ASan instrumentation for globals)
- #131505 (use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin)
- #132949 (Add specific diagnostic for using macro_rules macro as attribute/derive)
- #133286 (Re-delay a resolve `bug` related to `Self`-ctor in patterns)
- #133332 (Mark `<[T; N]>::as_mut_slice` with the `const` specifier.)
- #133366 (Remove unnecessary bool from `ExpectedFound::new`)
r? `@ghost`
`@rustbot` modify labels: rollup
Mark `<[T; N]>::as_mut_slice` with the `const` specifier.
Tracking issue: #133333
`<[T; N]>::as_mut_slice` can have the `const` specifier without any changes to the function body.
Re-delay a resolve `bug` related to `Self`-ctor in patterns
For the code pattern reported in <https://github.com/rust-lang/rust/issues/133272>,
```rs
impl Foo {
fn fun() {
let S { ref Self } = todo!();
}
}
```
<https://github.com/rust-lang/rust/pull/121208> converted this to a `span_bug` from a `span_delayed_bug` because this specific self-ctor code pattern lacked test coverage. It turns out this can be hit but we just lacked test coverage, so change it back to a `span_delayed_bug` and add a targeted test case.
Follow-up to #121208, cc ``@nnethercote`` (very good exercise to expose our test coverage gaps).
Fixes#133272.
Allow disabling ASan instrumentation for globals
AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them.
This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions.
(cc https://github.com/rust-lang/rust/issues/39699)
Rollup of 8 pull requests
Successful merges:
- #132090 (Stop being so bail-y in candidate assembly)
- #132658 (Detect const in pattern with typo)
- #132911 (Pretty print async fn sugar in opaques and trait bounds)
- #133102 (aarch64 softfloat target: always pass floats in int registers)
- #133159 (Don't allow `-Zunstable-options` to take a value )
- #133208 (generate-copyright: Now generates a library file too.)
- #133215 (Fix missing submodule in `./x vendor`)
- #133264 (implement OsString::truncate)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix missing submodule in `./x vendor`
The `src/tools/rustc-perf` submodule is needed for vendoring because it is included in the vendor set.
To test this:
1. Get a fresh clone of `rust-lang/rust`
2. `./x vendor`
generate-copyright: Now generates a library file too.
We only run reuse once, so the output has to be filtered to find only the files that are relevant to the library tree.
Outputs COPYRIGHT.html and COPYRIGHT-library.html.
The license-metadata.json file is also now in the tree. We need a CI tool to check that it's correct.
r? kobzol
Remaining steps:
* [ ] Teach CI to double-check the license-metadata.json file is correct
* [ ] Add the COPYRIGHT.html and COPYRIGHT-license.html to the releases
Don't allow `-Zunstable-options` to take a value
Passing an explicit boolean value (`-Zunstable-options=on`, `off` etc.) sometimes appears to work, but actually puts the compiler into an unintended state where unstable _options_ are still forbidden, but unstable values of _some_ stable options are allowed.
This is a result of `-Zunstable-options` being checked in multiple different places, in slightly different ways. Fixing the checks in `config::nightly_options` to understand boolean values would be non-trivial, so for now it's easier to make things consistent by forbidding values in the `-Z` parser.
---
There were a few uses of this in tests, which happened to work because they were tests of unstable values.
aarch64 softfloat target: always pass floats in int registers
This is a part of https://github.com/rust-lang/rust/issues/131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI.
Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that.
So we follow the aarch64 [softfloat ABI](https://github.com/rust-lang/rust/issues/131058#issuecomment-2385027423) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection.
Cc ```@workingjubilee```
Detect const in pattern with typo
When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.
```
error: unreachable pattern
--> $DIR/const-with-typo-in-pattern-binding.rs:30:9
|
LL | GOOOD => {}
| ----- matches any value
LL |
LL | _ => {}
| ^ no value can reach this
|
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
|
LL | GOOD => {}
| ~~~~
```
Fix#132582.
Stop being so bail-y in candidate assembly
A conceptual follow-up to #132084. We gotta stop bailing so much when there are errors; it's both unnecessary, leads to weird knock-on errors, and it's messing up the vibes lol
Implement `~const Destruct` effect goal in the new solver
This also fixed a subtle bug/limitation of the `NeedsConstDrop` check. Specifically, the "`Qualif`" API basically treats const drops as totally structural, even though dropping something that has an explicit `Drop` implementation cannot be structurally decomposed. For example:
```rust
#![feature(const_trait_impl)]
#[const_trait] trait Foo {
fn foo();
}
struct Conditional<T: Foo>(T);
impl Foo for () {
fn foo() {
println!("uh oh");
}
}
impl<T> const Drop for Conditional<T> where T: ~const Foo {
fn drop(&mut self) {
T::foo();
}
}
const FOO: () = {
let _ = Conditional(());
//~^ This should error.
};
fn main() {}
```
In this example, when checking if the `Conditional(())` rvalue is const-drop, since `Conditional` has a const destructor, we would previously recurse into the `()` value and determine it has nothing to drop, which means that it is considered to *not* need a const drop -- even though dropping `Conditional(())` would mean evaluating the destructor which relies on that `T: const Foo` bound to hold!
This could be fixed alternatively by banning any const conditions on `const Drop` impls, but that really sucks -- that means that basically no *interesting* const drop impls could be written. We have the capability to totally and intuitively support the right behavior, which I've implemented here.
Stabilize the 2024 edition
This stabilizes the 2024 edition for Rust 1.85, scheduled to be released on February 20, 2025. 🎉
cc tracking issue: https://github.com/rust-lang/rust/issues/117258
There is a fair amount of follow-up work after this that I am working on (various docs, cargo, rustfmt, etc.), and this is will unblock those other changes.
Rollup of 8 pull requests
Successful merges:
- #133238 (re-export `is_loongarch_feature_detected`)
- #133288 (Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.)
- #133311 (Miri subtree update)
- #133313 (Use arc4random of libc for RTEMS target)
- #133319 (Simplify `fulfill_implication`)
- #133323 (Bail in effects in old solver if self ty is ty var)
- #133330 (library: update comment around close())
- #133337 (Fix typo in `std:🧵:Scope::spawn` documentation.)
r? `@ghost`
`@rustbot` modify labels: rollup
Bail in effects in old solver if self ty is ty var
Otherwise when we try to check something like `?t: ~const Trait` we'll immediately stick it to the first param-env candidate, lol.
r? lcnr
Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.
Tracking issue: #133289
The methods `<[T; N]>::each_ref` and `<[T; N]>::each_mut` can easily be reimplemented to allow marking them with the `const` specifier.
This specific implementation takes a different approach than the original as to avoid using iterators (which are illegal in constant expressions).
