ICE: builtin attribute "should_panic" not handled by CheckAttrVisitor
#128622
Assignees
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
matthiaskrgr
added
I-ICE
rustbot
added
the
needs-triage
fn main() {
#[deny::skip]
foo();
} |
|
there are a bunch more which probably all follow the |
|
Taking a look |
Problem is the previous match [sym::ignore] | [sym::should_panic] => {
self.check_generic_attr(hir_id, attr, target, Target::Fn)
}falls through to the match BUILTIN_ATTRIBUTE_MAP.get(name) {
// checked below
Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
Some(_) => {
// FIXME: differentiate between unstable and internal attributes just
// like we do with features instead of just accepting `rustc_`
// attributes by name. That should allow trimming the above list, too.
if !name.as_str().starts_with("rustc_") {
span_bug!(
attr.span,
"builtin attribute {name:?} not handled by `CheckAttrVisitor`"
)
}
}
None => (),
}... and then since |
|
I have a candidate fix locally, doing some more testing |
jieyouxu
added
A-attributes
rust-cloud-vms bot
pushed a commit
to jieyouxu/rust
that referenced
this issue
Aug 4, 2024
…d" assertion ICE See <rust-lang#128622>.
rust-cloud-vms bot
pushed a commit
to jieyouxu/rust
that referenced
this issue
Aug 4, 2024
PR rust-lang#128581 introduced an assertion that all builtin attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes. Unfortunately, the check had correctness problems. The match on attribute path segments looked like ```rust,ignore [sym::should_panic] => /* check is implemented */ match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { if !name.as_str().starts_with("rustc_") { span_bug!( attr.span, "builtin attribute {name:?} not handled by `CheckAttrVisitor`" ) } } None => (), } ``` However, it failed to account for edge cases such as an attribute whose: 1. path segments *starts* with a builtin attribute such as `should_panic` 2. which does not start with `rustc_`, and 3. is also an `AttributeType::Normal` attribute upon registration with the builtin attribute map These conditions when all satisfied cause the span bug to be issued for e.g. `#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's `[sym::should_panic, sym::skip]`). See <rust-lang#128622>.
|
Opened #128623 as a candidate fix. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Aug 5, 2024
…cote Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment ### The Problem In rust-lang#128581 I introduced an assertion to check that all builtin attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes. Unfortunately, the assertion had correctness problems as revealed in rust-lang#128622. The match on attribute path segments looked like ```rs,ignore // Normal handler [sym::should_panic] => /* check is implemented */ // Fallback handler [name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { if !name.as_str().starts_with("rustc_") { span_bug!( attr.span, "builtin attribute {name:?} not handled by `CheckAttrVisitor`" ) } } None => (), } ``` However, it failed to account for edge cases such as an attribute whose: 1. path segments *starts* with a segment matching the name of a builtin attribute such as `should_panic`, and 2. the first segment's symbol does not start with `rustc_`, and 3. the matched builtin attribute is also of `AttributeType::Normal` attribute type upon registration with the builtin attribute map. These conditions when all satisfied cause the span bug to be issued for e.g. `#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's `[sym::should_panic, sym::skip]`). ### Proposed Solution This PR tries to remedy that by adjusting all normal/specific handlers to not match exactly on a single segment, but instead match a prefix segment. i.e. ```rs,ignore // Normal handler, notice the `, ..` rest pattern [sym::should_panic, ..] => /* check is implemented */ // Fallback handler [name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { if !name.as_str().starts_with("rustc_") { span_bug!( attr.span, "builtin attribute {name:?} not handled by `CheckAttrVisitor`" ) } } None => (), } ``` ### Review Remarks This PR contains 2 commits: 1. The first commit adds a regression test. This will ICE without the `CheckAttrVisitor` changes. 2. The second commit adjusts `CheckAttrVisitor` assertion logic. Once this commit is applied, the test should no longer ICE and produce the expected bless stderr. Fixes rust-lang#128622. r? `@nnethercote` (since you reviewed rust-lang#128581)
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 5, 2024
Rollup merge of rust-lang#128623 - jieyouxu:check-attr-ice, r=nnethercote Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment ### The Problem In rust-lang#128581 I introduced an assertion to check that all builtin attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes. Unfortunately, the assertion had correctness problems as revealed in rust-lang#128622. The match on attribute path segments looked like ```rs,ignore // Normal handler [sym::should_panic] => /* check is implemented */ // Fallback handler [name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { if !name.as_str().starts_with("rustc_") { span_bug!( attr.span, "builtin attribute {name:?} not handled by `CheckAttrVisitor`" ) } } None => (), } ``` However, it failed to account for edge cases such as an attribute whose: 1. path segments *starts* with a segment matching the name of a builtin attribute such as `should_panic`, and 2. the first segment's symbol does not start with `rustc_`, and 3. the matched builtin attribute is also of `AttributeType::Normal` attribute type upon registration with the builtin attribute map. These conditions when all satisfied cause the span bug to be issued for e.g. `#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's `[sym::should_panic, sym::skip]`). ### Proposed Solution This PR tries to remedy that by adjusting all normal/specific handlers to not match exactly on a single segment, but instead match a prefix segment. i.e. ```rs,ignore // Normal handler, notice the `, ..` rest pattern [sym::should_panic, ..] => /* check is implemented */ // Fallback handler [name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { if !name.as_str().starts_with("rustc_") { span_bug!( attr.span, "builtin attribute {name:?} not handled by `CheckAttrVisitor`" ) } } None => (), } ``` ### Review Remarks This PR contains 2 commits: 1. The first commit adds a regression test. This will ICE without the `CheckAttrVisitor` changes. 2. The second commit adjusts `CheckAttrVisitor` assertion logic. Once this commit is applied, the test should no longer ICE and produce the expected bless stderr. Fixes rust-lang#128622. r? ``@nnethercote`` (since you reviewed rust-lang#128581)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustcProgram output
The text was updated successfully, but these errors were encountered: