Pre lint port cleanups - #162813
Pre lint port cleanups#162813
Conversation
… drop dead default_method_body_is_const lint
|
Some changes occurred in compiler/rustc_passes/src/check_attr.rs |
|
rustbot has assigned @JonathanBrouwer. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| #[expect[wut]] // OK | ||
| #[expect(expect)] // OK | ||
| #[expect(expect(expect))] //~ ERROR malformed lint attribute input | ||
| //~| ERROR malformed lint attribute input |
There was a problem hiding this comment.
This also should be ok.
Before the const _ item is fully expanded (the item itself, not its nested nodes), all the #[expect]s (and other potential inert attributes) are just tokens without any semantic meaning, and the active attributes can change those tokens in any way or remove them like cfg(false) does, so any semantic checks like "this built-in attribute has unexpected input" should not be performed for them.
There was a problem hiding this comment.
In this sense
#[expect(expect(expect))]
expand_to_nothing!();is also equivalent to #[expect(expect(expect))] in cfg(false) code, and also shouldn't report any "malformed" attribute errors, and #160904 is not doing the right thing.
Although it would still be nice to conservatively turn it into an error, and then try turning #[attrs] in #[attrs] mac_call!() into a part of the macro input (#63221 (comment)).
There was a problem hiding this comment.
This also should be ok.
I agree, it's annoyingly inconsistent. I'm just adding the test here to document the current behavior and I don't want to change that behavior before or during #162811 because it'll make porting lint attributes much harder to write and review.
Before the
const _item is fully expanded (the item itself, not its nested nodes), all the#[expect]s (and other potential inert attributes) are just tokens without any semantic meaning ...
They have meaning for pre-expansion lints, so it's not as simple as "they're just tokens":
//@ edition: 2015
#[warn(keyword_idents_2024)]
#[cfg(false)]
fn foo() {
let gen = 5; //~ WARN `gen` is a keyword in the 2024 edition
}There was a problem hiding this comment.
Since when the example with #[warn(keyword_idents_2024)] works, and how?
Previously lint attributes were only attached to node ids, and node ids are not created for cfg(false) code.
I don't think it's generally a good idea to support this, if it goes against the core expansion model.
There was a problem hiding this comment.
I don't want to change that behavior before or during #162811 because it'll make porting lint attributes much harder to write and review.
With this I agree.
There was a problem hiding this comment.
This equivalent example works in rust 1.30:
//@ edition: 2015
#[warn(keyword_idents)]
#[cfg(any())]
fn foo() {
let async = 5; // `async` is a keyword in the 2018 edition
}There was a problem hiding this comment.
Hmm, weird, I need to investigate.
|
r=me |
|
I'd like to take a look at this as well, can probably make some time tonight |
…uwer Rollup of 7 pull requests Successful merges: - #161873 (move bug and span_bug macros to rustc_span) - #162584 (Use File::*lock*() in rustc_data_structures::flock when possible) - #162704 (Parser: Uninterpolate when checking for const closures, try bikeshed blocks & in relevant diagnostic code) - #162787 (Fix suggestions for names captured by formatting macros) - #159562 (Windows: cache the stdio write mode for the duration of a lock session) - #162813 (Pre lint port cleanups) - #162822 (PassWrapper: adapt for removal of EABIVersion arg in LLVM 24)
Rollup merge of #162813 - mejrs:pre_lint_cleanups, r=JonathanBrouwer,petrochenkov Pre lint port cleanups Some minor changes split off from #162811, to make that a bit easier to review. cc @JonathanBrouwer
Some minor changes split off from #162811, to make that a bit easier to review.
cc @JonathanBrouwer