[codex] tests: mark migrated UI tests as check-pass
## Summary
Migrate a small set of UI tests left behind by the `compile-pass` migration from `build-pass` to `check-pass`.
These tests exercise attributes, cfg_attr, range trait type checking, and reachable-code diagnostics. None of the changed tests need codegen or linking, so `check-pass` matches the intended coverage and removes the stale `FIXME(#62277)` notes.
## Validation
- `python x.py test tests/ui/attributes/attr-before-view-item.rs tests/ui/attributes/attr-before-view-item2.rs tests/ui/attributes/attr-mix-new.rs tests/ui/attributes/class-attributes-1.rs tests/ui/attributes/class-attributes-2.rs tests/ui/attributes/method-attributes.rs tests/ui/attributes/unrestricted-attribute-tokens.rs tests/ui/attributes/variant-attributes.rs tests/ui/conditional-compilation/cfg-attr-multi-false.rs tests/ui/conditional-compilation/cfg-attr-multi-true.rs tests/ui/range/range_traits-4.rs tests/ui/range/range_traits-5.rs tests/ui/range/range_traits-7.rs tests/ui/reachable/expr_andand.rs tests/ui/reachable/expr_oror.rs`
- `python x.py test tidy`
Fix attribute order implementation
The implementation in https://github.com/rust-lang/rust/pull/153041 contained a mistake :c
I swapped the place where the error message was on, but did not change any code for which attribute was also selected, which explains the empty crater results.
**Interestingly, the original code is broken too, before https://github.com/rust-lang/rust/pull/153041 it always took the last attribute, regardless of what the `AttributeOrder` actually was...**
Let's first see crater results before making a decision
TODO for this PR: Make better tests for this
Make `span_suggestions` always verbose
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
Clean up `AttributeLintKind` and refactor diagnostic attribute linting
There was a fair amount of duplication here, and thanks to the proliferation of new diagnostic attributes these days, it was threatening to grow bigger.
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
also removes E0452 and splits
`tests/rustdoc-ui/lints/renamed-lint-still-applies` into 2 tests
this is because of delayed warn lint being lost on compiler aborting on
error
diagnostics: avoid ICE in confusable_method_name for associated functions
Avoid unconditionally slicing `inputs()[1..]`, which assumes a `self` parameter. Use `is_method()` to conditionally skip the receiver, preventing out-of-bounds access and fixing suggestions for associated functions.
Avoid unconditionally slicing `inputs()[1..]`, which assumes a `self`
parameter. Use `is_method()` to conditionally skip the receiver,
preventing out-of-bounds access and fixing suggestions for associated
functions.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
Move some ui tests
> [!NOTE]
> I split the commits to make the review easier and to keep the git history easier to trace.
Renamed issue-xxx tests
`tests/ui/dyn-drop` -> `tests/ui/dyn-keyword`
`tests/ui/missing-trait-bounds` -> `tests/ui/trait-bound/missing-trait-bounds`
`tests/ui/recursion_limit` -> `tests/ui/recursion/recursion_limit`
`tests/ui/version` -> `tests/ui/compile-flags`
Reorganize `tests/ui/empty`
* Move dyn-drop to dyn-keyword
* Reorganize `tests/ui/empty` into specific dirs
remove tests/ui/empty/empty-linkname.rs duplicate of tests/ui/error-codes/E0454.rs
* Move `missing-trait-bounds` to `trait-bound/missing-trait-bounds`
* bless traits/missing-trait-bounds tests
* Move `recursion_limit` to `recursion/recursion_limit`
* Move `version` to `compile-flags`
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Add FCW for derive helper attributes that will conflict with built-in attributes
Adds a future-compatibility-warning deny-by-default lint that helps catch invalid derive helper attribute names early.
This issues the lint, saying that `ignore` helper will clash with the built-in `ignore` attribute.
```rust
#![crate_type = "proc-macro"]
#![deny(ambiguous_derive_helpers)]
use proc_macro::TokenStream;
#[proc_macro_derive(Trait, attributes(ignore))]
pub fn example(input: TokenStream) -> TokenStream {
TokenStream::new()
}
```
If you actually tried to use that `ignore` helper attribute, you won't be able to due to the ambiguity:
```rust
#[derive(Trait)]
struct Foo {
#[ignore]
field: (),
}
```
Produces:
```
error[E0659]: `ignore` is ambiguous
--> src/lib.rs:5:7
|
5 | #[ignore]
| ^^^^^^ ambiguous name
|
= note: ambiguous because of a name conflict with a builtin attribute
= note: `ignore` could refer to a built-in attribute
note: `ignore` could also refer to the derive helper attribute defined here
--> src/lib.rs:3:10
|
3 | #[derive(Trait)]
| ^^^^^
```
danieljofficial