Fix ICE when applying test macro to crate root
This PR does a couple of things. First of all, I found [an ICE](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a733a7f3d223e1a9712e44b571f3e5cf) that happens when applying `#![core::prelude::v1::test]` to the crate root. This is caused by the test macro not expanding to an item when `--test` isn't applied. For the crate root, that means it deletes the crate....
The fix now first does target checking, and only if the target is valid discards the item when `--test` isn't applied. The discarding is, I think, important for perf.
The problem with this PR is that it means that `#[test]` applied to structs previously would give no errors unless `--test` is applied! That sounds like a bug to me, but maybe we should crater run it just in case, since technically that's a breaking change. Errors in such items wouldn't be reported previously.
Also fixed a smol diagnostics bug with `#[bench]`'s error messages refering to `#[test]` accidentally.
r? noratrieb (since I already explained you a bunch, feel free to re-assign)
Fixes https://github.com/rust-lang/rust/issues/114920
Gate tests with the right edition
This PR guarantees that `./x test --test-args="--edition XXXX" ui` runs correctly with the 2015, 2018 and 2021 editions.
I don't expect this PR to hold up over time but it helps to submit further updates to the `//@ edition` directives of tests where we can use the new range syntax to have a more robust testing across different editions
r? `@fmease`
---
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu
Port the `#![windows_subsystem]` attribute to the new attribute system
Part of rust-lang/rust#131229.
I think it's worth running the Windows test suite before merging that (I don't have the rights for this).
Add a diagnostic attribute for special casing const bound errors for non-const impls
Somewhat of a follow-up to https://github.com/rust-lang/rust/pull/144194
My plan is to resolve
f4e19c6878/compiler/rustc_hir_typeck/src/callee.rs (L907-913)
but doing so without being able to mark impls the way I do in this PR wrould cause all nice diagnostics about for loops and pointer comparisons to just be a `*const u32 does not implement [const] PartialEq` errors.
Stabilize `asm_cfg`
tracking issue: https://github.com/rust-lang/rust/issues/140364
closes https://github.com/rust-lang/rust/issues/140364
Reference PR:
- https://github.com/rust-lang/reference/pull/2063
# Request for Stabilization
## Summary
The `cfg_asm` feature allows `#[cfg(...)]` and `#[cfg_attr(...)]` on the arguments of the assembly macros, for instance:
```rust
asm!( // or global_asm! or naked_asm!
"nop",
#[cfg(target_feature = "sse2")]
"nop",
// ...
#[cfg(target_feature = "sse2")]
a = const 123, // only used on sse2
);
```
## Semantics
Templates, operands, `options` and `clobber_abi` in the assembly macros (`asm!`, `naked_asm!` and `global_asm!`) can be annotated with `#[cfg(...)]` and `#[cfg_attr(...)]`. When the condition evaluates to true, the annotated argument has no effect, and is completely ignored when expanding the assembly macro.
## Documentation
reference PR: https://github.com/rust-lang/reference/pull/2063
## Tests
- [tests/ui/asm/cfg.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks that `cfg`'d arguments where the condition evaluates to false have no effect
- [tests/ui/asm/cfg-parse-error.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks the parsing rules (parsing effectively assumes that the cfg conditions are all true)
## History
- https://github.com/rust-lang/rust/issues/140279
- https://github.com/rust-lang/rust/pull/140367
# Resolved questions
**how are other attributes handled**
Other attributes are parsed, but explicitly rejected.
# unresolved questions
**operand before template**
The current implementation expects at least one template string before any operands. In the example below, if the `cfg` condition evaluates to true, the assembly block is ill-formed. But even when it evaluates to `false` this block is rejected, because the parser still expects just a template (a template is parsed as an expression and then validated to ensure that it is or expands to a string literal).
Changing how this works is difficult.
```rust
// This is rejected because `a = out(reg) x` does not parse as an expresion.
asm!(
#[cfg(false)]
a = out(reg) x, //~ ERROR expected token: `,`
"",
);
```
**lint on positional arguments?**
Adding a lint to warn on the definition or use of positional arguments being `cfg`'d out was discussed in https://github.com/rust-lang/rust/issues/140279#issuecomment-2832237372 and subsequent comments. Such a lint is not currently implemented, but that may not be a blocker based on the comments there.
r? `@traviscross` (I'm assuming you'll reassign as needed)
When a trait isn't implemented, but another similar impl is found, point at it
```
error[E0277]: the trait bound `u32: Trait` is not satisfied
--> $DIR/trait_objects_fail.rs:26:9
|
LL | foo(&10_u32);
| ^^^^^^^ the trait `Trait` is not implemented for `u32`
|
help: the trait `Trait<12>` is not implemented for `u32`
but trait `Trait<2>` is implemented for it
--> $DIR/trait_objects_fail.rs:7:1
|
LL | impl Trait<2> for u32 {}
| ^^^^^^^^^^^^^^^^^^^^^
= note: required for the cast from `&u32` to `&dyn Trait`
```
Pointing at the `impl` definition that *could* apply given a different self type is *particularly* useful when it has a blanket self type, as it might not be obvious and is not trivially greppable:
```
error[E0277]: the trait bound `RawImpl<_>: Raw<_>` is not satisfied
--> $DIR/issue-62742.rs:4:5
|
LL | WrongImpl::foo(0i32);
| ^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Raw<_>` is not implemented for `RawImpl<_>`
but trait `Raw<[_]>` is implemented for it
--> $DIR/issue-62742.rs:29:1
|
LL | impl<T> Raw<[T]> for RawImpl<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `SafeImpl`
--> $DIR/issue-62742.rs:33:35
|
LL | pub struct SafeImpl<T: ?Sized, A: Raw<T>>(PhantomData<(A, T)>);
| ^^^^^^ required by this bound in `SafeImpl`
```
```
error[E0277]: the trait bound `[[u16; 3]; 2]: Bar` is not satisfied
--> $DIR/issue-67185-2.rs:21:6
|
LL | impl Foo for FooImpl {}
| ^^^ the trait `Bar` is not implemented for `[[u16; 3]; 2]`
|
help: the following other types implement trait `Bar`
--> $DIR/issue-67185-2.rs:9:1
|
LL | impl Bar for [u16; 4] {}
| ^^^^^^^^^^^^^^^^^^^^^ `[u16; 4]`
LL | impl Bar for [[u16; 3]; 3] {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `[[u16; 3]; 3]`
note: required by a bound in `Foo`
--> $DIR/issue-67185-2.rs:14:30
|
LL | trait Foo
| --- required by a bound in this trait
LL | where
LL | [<u8 as Baz>::Quaks; 2]: Bar,
| ^^^ required by this bound in `Foo`
```
Remove needs-asm-support directive in tests with explicit targets
The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary.
These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.
Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
Further tighten up relaxed bounds
Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841.
Fixesrust-lang/rust#143122.
* Reject relaxed bounds `?Trait` in the bounds of trait aliases.
Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden.
* Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled.
That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation).
* Unconditionally check that the `Trait` in `?Trait` is a default trait.
Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through.
* Slightly improve diagnostics.
The `needs-asm-support` directive checks whether the host architecture
supports inline assembly, not the target architecture. For tests that
explicitly specify a target via `--target` in their compile-flags, this
directive is incorrect and unnecessary.
These tests are cross-compiling to specific targets (like x86_64, arm,
aarch64, riscv, etc.) that are already known to have stable asm support.
The directive was causing these tests to be incorrectly skipped on hosts
that don't support asm, even though the target does.
Tests with explicit targets should rely on `needs-llvm-components` to
ensure the appropriate backend is available, rather than checking host
asm support.
Improve documentation about `needs-asm-support` directive.
only replace the intended comma in pattern suggestions
Only suggest to replace the intended comma, not all bars in the pattern.
Fixesrust-lang/rust#143330.
This continues rust-lang/rust#143331, the credit for making the fix goes to `@A4-Tacks.` I just blessed tests and added a regression test.
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
Clarified error note for usize range matching
Fixesrust-lang/rust#146476
This is kinda rough, but it gets the point across a little better and stays short.
Introduce CoerceShared lang item and trait, and basic Reborrow tests
Part of rust-lang/rust#145612: This introduces the `CoerceShared` trait which is the `Reborrow` equivalent of a `&mut T` -> `&T` coercion. The trait has a `Target` GAT which makes this (currently) unique in the `core/src/marker.rs`; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.
Improtantly, this PR introduces a battery of basic `Reborrow` and `CoerceShared` tests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (`Custom<'a>(PhantomData<&'a mut ()>)`), custom exclusive reference wrappers, and standard library exclusive reference wrappers (`Pin<&mut T>` and `Option<&mut T>`). None of these of course work since the implementation for `Reborrow` and `CoerceShared` is entirely missing, but this is the first step towards making these work.
Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.
