Fix breakage when running compiletest with `--test-args=--edition=2015`
Compiletest has an `--edition` flag to change the default edition tests are run with. Unfortunately no test suite successfully executes when that flag is passed. If the edition is set to something greater than 2015 the breakage is expected, since the test suite currently supports only edition 2015 (Ferrous Systems will open an MCP about fixing that soonish). Surprisingly, the test suite is also broken if `--edition=2015` is passed to compiletest. This PR focuses on fixing the latter.
This PR fixes the two categories of failures happening when `--edition=2015` is passed:
* Some edition-specific tests set their edition through `//@ compile-flags` instead of `//@ edition`. Compiletest doesn't parse the compile flags, so it would see no `//@ edition` and add another `--edition` flag, leading to a rustc error.
* Compiletest would add the edition after `//@ compile-flags`, while some tests depend on flags passed to `//@ compile-flags` being the last flags in the rustc invocation.
Note that for the first category, I opted to manually go and replace all `//@ compile-flags` setting an edition with an explicit `//@ edition`. We could've changed compiletest to instead check whether an edition was set in `//@ compile-flags`, but I thought it was better to enforce a consistent way to set the edition in tests.
I also added the edition to the stamp, so that changing `--edition` results in tests being re-executed.
r? `@jieyouxu`
Improve `AssocItem::descr`.
The commit adds "associated" to the description of associated types and associated consts, to match the description of associated functions. This increases error message precision and consistency with `AssocKind::fmt`.
The commit also notes an imperfection in `AssocKind::fmt`; fixing this imperfection is possible but beyond the scope of this PR.
r? `@estebank`
Allow parenthesis around inferred array lengths
In #135272 it was noticed that we weren't handling `Vec<(((((_)))))>` correctly under the new desugaring for `generic_arg_infer`, this had to be fixed in order to not regress stable code for types that should continue working. This has the side effect of *also* allowing the following to work:
```rust
#![feature(generic_arg_infer)]
struct Bar<const N: usize>;
fn main() {
let a: Bar<((_))> = Bar::<10>;
}
```
However I did not make the same change for array lengths resulting in the following not compiling:
```rust
#![feature(generic_arg_infer)]
fn main() {
let a: [u8; (((_)))] = [2; 2];
let a: [u8; 2] = [2; (((((_)))))];
}
```
This is rather inconsistent as parenthesis around `_` *are* supported for const args to non-arrays, and type args. This PR fixes this allowing the above example to compile. No stable impact.
r? compiler-errors
Deeply normalize obligations in `BestObligation` folder
Built on #139513.
This establishes a somewhat rough invariant that the `Obligation`'s predicate is always deeply normalized in the folder; when we construct a new obligation we normalize it.
Putting this up for discussion since it does affect some goals.
r? lcnr
Introduce a `//@ needs-crate-type` compiletest directive
The `//@ needs-crate-type: $crate_types...` directive takes a comma-separated list of crate types that the target platform must support in order for the test to be run. This allows the test writer to semantically convey that the ignore condition is based on target crate type needs, instead of using a general purpose `//@ ignore-$target` directive (often without comment).
Fixes#132309.
### Example
```rs
//@ needs-crate-type: dylib (ignored on e.g. wasm32-unknown-unknown)
//@ compile-flags: --crate-type=dylib
fn foo() {}
```
### Review advice
- Best reviewed commit-by-commit.
- The impl is not very clean, I briefly attempted to clean up the directive handling but found that more invasive changes are needed, so I'd like to not block on the cleanup for now.
try-job: test-various
try-job: armhf-gnu
Allow drivers to supply a list of extra symbols to intern
Allows adding new symbols as `const`s in external drivers, desirable in Clippy so we can use them in patterns to replace code like 75530e9f72/src/tools/clippy/clippy_lints/src/casts/cast_ptr_alignment.rs (L66)
The Clippy change adds a couple symbols as a demo, the exact `clippy_utils` API and replacing other usages can be done on the Clippy side to minimise sync conflicts
---
try-job: aarch64-gnu
rustc_target: update x86_win64 to match the documented calling convention for f128
llvm/llvm-project@5ee1c0b714 updates llvm to match the documented calling convention to pass f128 indirectly. This change makes us do that on all versions of LLVM, not just starting with LLVM 21.
`@rustbot` label llvm-main
try-job: dist-x86_64-msvc
try-job: dist-x86_64-mingw
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
add `core::intrinsics::simd::{simd_extract_dyn, simd_insert_dyn}`
fixes https://github.com/rust-lang/rust/issues/137372
adds `core::intrinsics::simd::{simd_extract_dyn, simd_insert_dyn}`, which contrary to their non-dyn counterparts allow a non-const index. Many platforms (but notably not x86_64 or aarch64) have dedicated instructions for this operation, which stdarch can emit with this change.
Future work is to also make the `Index` operation on the `Simd` type emit this operation, but the intrinsic can't be used directly. We'll need some MIR shenanigans for that.
r? `@ghost`
The commit adds "associated" to the description of associated types and
associated consts, to match the description of associated functions.
This increases error message precision and consistency with
`AssocKind::fmt`.
The commit also notes an imperfection in `AssocKind::fmt`; fixing this
imperfection is possible but beyond the scope of this PR.
Ensure `swap_nonoverlapping` is really always untyped
This replaces #134954, which was arguably overcomplicated.
## Fixes#134713
Actually using the type passed to `ptr::swap_nonoverlapping` for anything other than its size + align turns out to not work, so this goes back to always erasing the types down to just bytes.
(Except in `const`, which keeps doing the same thing as before to preserve `@RalfJung's` fix from #134689)
## Fixes#134946
I'd previously moved the swapping to use auto-vectorization *on bytes*, but someone pointed out on Discord that the tail loop handling from that left a whole bunch of byte-by-byte swapping around. This goes back to manual tail handling to avoid that, then still triggers auto-vectorization on pointer-width values. (So you'll see `<4 x i64>` on `x86-64-v3` for example.)
Remove unnecessary `mut` in test.
The value is moved in `pin!()`, so the binding doesn't need to be `mut` itself.
(Rustc doesn't warn about this due to the current hacky implementation of `pin!()`. That is fixed by https://github.com/rust-lang/rust/pull/139114.)
Rename some `name` variables as `ident`.
It bugs me when variables of type `Ident` are called `name`. It leads to silly things like `name.name`. `Ident` variables should be called `ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of `Ident` variables. Not all of them, but a decent chunk.
r? `@fee1-dead`
fix "still mutable" ice while metrics are enabled
Resolves "still mutable" ICE discovered by `@matthiaskrgr` here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/510490790)
This was caused by invoking `crate_hash` before the `definitions` struct was frozen here: e643f59f6d/compiler/rustc_interface/src/passes.rs (L951)
resolved by moving metrics dumping to occur after `analysis` freezes the definitions
I'm guessing we didn't discover this in CI because the problem only occurs when you try to calculate the crash hash with incremental compilation enabled when it tries to freeze the definitions here: e643f59f6d/compiler/rustc_middle/src/hir/map.rs (L1172)
my understanding is that this causes us to freeze the definitions too early in compilation, then we subsequently try to mutate them, likely during `analysis`, and this causes the ICE.
r? `@bjorn3`
Rollup of 13 pull requests
Successful merges:
- #138167 (Small code improvement in rustdoc hidden stripper)
- #138605 (Clean up librustdoc::html::render to be better encapsulated)
- #139423 (Suppress missing field error when autoderef bottoms out in infer)
- #139449 (match ergonomics: replace `peel_off_references` with a recursive call)
- #139507 (compiletest: Trim whitespace from environment variable names)
- #139530 (Remove some dead or leftover code related to rustc-intrinsic abi removal)
- #139560 (fix title of offset_of_enum feature)
- #139563 (emit a better error message for using the macro incorrectly)
- #139568 (Don't use empty trait names)
- #139580 (Temporarily leave the review rotation)
- #139589 (saethlin is back from vacation)
- #139592 (rustdoc: Enable Markdown extensions when looking for doctests)
- #139599 (Tracking issue template: fine-grained information on style update status)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Enable Markdown extensions when looking for doctests
Fixes#139064.
We should enable these to avoid misinterpreting uses of the extended
syntax as code blocks. This happens in practice with multi-paragraph
footnotes, as discovered in #139064.
emit a better error message for using the macro incorrectly
fixing: https://github.com/EnzymeAD/rust/issues/185
I feel like it's not a perfect message either, so I'm open to suggestions.
But at the end of the day users will need to read the docs anyway, and emitting
multi-line errors each time this gets triggered can probably become annoying?
r? ``@jieyouxu`` since you've reviewed my frontend work back in the days.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
compiletest: Trim whitespace from environment variable names
When a test contains a directive like `//@ exec-env: FOO=bar`, compiletest currently includes that leading space in the name of the environment variable, so it is defined as ` FOO` instead of `FOO`.
This is an annoying footgun that is pretty much never intended, especially since most other directives *do* trim whitespace. So let's get rid of it by trimming the environment variable name.
Values remain untrimmed, since there could conceivably be a use-case for values with leading space, but perhaps we'll end up trimming values too in the future.
Recently observed in https://github.com/rust-lang/rust/pull/138603#issuecomment-2783709359.
Fixes#132990.
Supersedes #133148.
---
try-job: test-various
Suppress missing field error when autoderef bottoms out in infer
I see this error repeatedly when doing refactorings, and it's pretty misleading b/c it's not the source of the error.
Note that some of the output is currently bogus, with missing params and
args:
```
fn add(: _, : _) -> _ { m::add(, ) }
```
The next commit will fix this.
Rigidly project missing item due to guaranteed impossible sized predicate
This is a somewhat involved change, but it amounts to treating missing impl items due to guaranteed impossible where clauses (dyn/str/slice sized, cc #135480) as *rigid projections* rather than projecting to an error term, since that was preventing either reporting a proper error (in an empty param env) *or* successfully type checking the code (in the presence of trivially false where clauses).
Fixes https://github.com/rust-lang/rust/issues/138970
r? `@lcnr` `@oli-obk`
It bugs me when variables of type `Ident` are called `name`. It leads to
silly things like `name.name`. `Ident` variables should be called
`ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of
`Ident` variables. Not all of them, but a decent chunk.
report call site of inlined scopes for large assignment lints
Addressed issue: #121672
Tracking issue: #83518
r? `@oli-obk`
I tried to follow your comment about what to do [here](https://github.com/rust-lang/rust/issues/121672#issuecomment-1972783675). However, I'm totally unfamiliar with the code so far (this is my first contribution touching compiler code), so I apologize in advance if I did something stupid 😅
In particular, I'm not sure I use the _correct_ source scope to look for inline data, as there is a whole `IndexVec` of them. My changes definitely did something, as can be seen by the added ui test. However, the result is not as anticipated in the issue:
```
LL | let cell = std::cell::UnsafeCell::new(data);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value moved from here
```
instead of
```
LL | let cell = std::cell::UnsafeCell::new(data);
| ^^^^ value moved from here
```
raising my suspicion that maybe I got the wrong source scope.
Report higher-ranked trait error when higher-ranked projection goal fails in new solver
~~See HACK comment inline. Not actually sure if it should be marked as a *HACK*, b/c~~ it's kinda a legitimate case we want to care about unless we're going to make the proof tree visitor *smarter* about the leak check than the actual trait solver itself.
Encountered this while battling with `NiceRegionError`s in the old solver b/c I wondered what this code ended up giving us in the *new* solver as a comparison:
```rust
trait Foo {}
impl<T: FnOnce(&())> Foo for T {}
fn baz<T: Foo>() {}
fn main() {
baz::<fn(&'static ())>();
}
```
On master it's pretty bad:
```
error[E0271]: type mismatch resolving `<fn(&()) as FnOnce<(&(),)>>::Output == ()`
--> <source>:8:11
|
8 | baz::<fn(&'static ())>();
| ^^^^^^^^^^^^^^^ types differ
|
note: required for `fn(&'static ())` to implement `Foo`
--> <source>:3:22
|
3 | impl<T: FnOnce(&())> Foo for T {}
| ----------- ^^^ ^
| |
| unsatisfied trait bound introduced here
```
After this PR it's much better:
```
error[E0277]: the trait bound `fn(&'static ()): Foo` is not satisfied
--> /home/mgx/test.rs:8:11
|
8 | baz::<fn(&'static ())>();
| ^^^^^^^^^^^^^^^ the trait `for<'a> FnOnce(&'a ())` is not implemented for `fn(&'static ())`
|
= note: expected a closure with arguments `(&'static (),)`
found a closure with arguments `(&(),)`
note: required for `fn(&'static ())` to implement `Foo`
--> /home/mgx/test.rs:3:22
|
3 | impl<T: FnOnce(&())> Foo for T {}
| ----------- ^^^ ^
| |
| unsatisfied trait bound introduced here
note: required by a bound in `baz`
--> /home/mgx/test.rs:5:11
|
5 | fn baz<T: Foo>() {}
| ^^^ required by this bound in `baz`
```
r? lcnr
compiletest: Add directive `dont-require-annotations`
for making matching on specific diagnostic kinds non-exhaustive.
E.g. `//@ dont-require-annotations:ERROR`, like in the examples in this PR.
cc https://github.com/rust-lang/rust/pull/139427#issuecomment-2782827583Closes#132647 FYI `@BoxyUwU` since you've wanted this.
r? `@jieyouxu`
speed up `String::push` and `String::insert`
Addresses the concerns described in #116235.
The performance gain comes mainly from avoiding temporary buffers.
Complex pattern matching in `encode_utf8` (introduced in #67569) has been simplified to a comparison and an exhaustive `match` in the `encode_utf8_raw_unchecked` helper function. It takes a slice of `MaybeUninit<u8>` because otherwise we'd have to construct a normal slice to uninitialized data, which is not desirable, I guess.
Several functions still have that [unneeded zeroing](https://rust.godbolt.org/z/5oKfMPo7j), but a single instruction is not that important, I guess.
`@rustbot` label T-libs C-optimization A-str
