ICE: adding a def'n for node-id NodeId(18) and def kind AnonConst but a previous def'n exists
#128016
Assignees
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-critical
Critical priority
regression-from-stable-to-beta
Performance or correctness regression from stable to beta.
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
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
matthiaskrgr
added
the
S-bug-has-test
saethlin
removed
the
needs-triage
matthiaskrgr
added
the
regression-from-stable-to-beta
rustbot
added
the
I-prioritize
|
This also showed up in the crater reports for #128468 |
|
Minimized a bit more (avoid incorrect macro_rules! len {
() => {
target
};
}
fn main() {
let val: [bool; len!()] = [];
} |
|
I'll look into this since this is on beta now so its somewhat time sensitive ^^' |
|
It seems like this is macro_rules! len {
() => {{
let target = 0;
target
}};
}
fn main() {
let val: [bool; len!()] = [];
}
|
|
How is it a non-const? is valid code. |
macro_rules! len {
() => {
BAR
};
}
const BAR: usize = 0;
fn bar() {
let val: [bool; len!()] = [];
}This is an example of stable->beta pass->ICE |
macro_rules! len {
($x:ident) => {
$x
};
}
fn bar<const N: usize>() {
let val: [bool; len!(N)] = [true; N];
}This has a slightly different ICE message but is the same root cause and is also a stable->beta pass->ICE |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-critical |
rustbot
added
P-critical
This was referenced Aug 18, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Aug 24, 2024
…h, r=cjgillot Retroactively feature gate `ConstArgKind::Path` This puts the lowering introduced by rust-lang#125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :) cc rust-lang#129137 `@camelid,` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta. Fixes rust-lang#128016
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 25, 2024
Rollup merge of rust-lang#129246 - BoxyUwU:feature_gate_const_arg_path, r=cjgillot Retroactively feature gate `ConstArgKind::Path` This puts the lowering introduced by rust-lang#125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :) cc rust-lang#129137 ``@camelid,`` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta. Fixes rust-lang#128016
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 13, 2024
Fix anon const def-creation when macros are involved Fixes rust-lang#128016. Ever since rust-lang#125915, some `ast::AnonConst`s turn into `hir::ConstArgKind::Path`s, which don't have associated `DefId`s. To deal with the fact that we don't have resolution information in `DefCollector`, we decided to implement a process where if the anon const *appeared* to be trivial (i.e., `N` or `{ N }`), we would avoid creating a def for it in `DefCollector`. If later, in AST lowering, we realized it turned out to be a unit struct literal, or we were lowering it to something that didn't use `hir::ConstArg`, we'd create its def there. However, let's say we have a macro `m!()` that expands to a reference to a free constant `FOO`. If we use `m!()` in the body of an anon const (e.g., `Foo<{ m!() }>`), then in def collection, it appears to be a nontrivial anon const and we create a def. But the macro expands to something that looks like a trivial const arg, but is not, so in AST lowering we "fix" the mistake we assumed def collection made and create a def for it. This causes a duplicate definition ICE. The long-term fix for this is to delay the creation of defs for all expression-like nodes until AST lowering (see rust-lang#128844 for an incomplete attempt at this). This would avoid issues like this one that are caused by hacky workarounds. However, doing this uncovers a pre-existing bug with opaque types that is quite involved to fix (see rust-lang#129023). In the meantime, this PR fixes the bug by delaying def creation for anon consts whose bodies are macro invocations until after we expand the macro and know what is inside it. This is accomplished by adding information to create the anon const's def to the data in `Resolver.invocation_parents`. r? `@BoxyUwU`
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: