ICE: inconsistent resolution for an import
#124490
Labels
A-resolve
Area: Name/path resolution done by `rustc_resolve` specifically
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
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
|
also crashes with just |
jieyouxu
added
A-resolve
|
Regression in nightly-2023-07-01 commit[0] 2023-06-29: Auto merge of #112682 - spastorino:new-rpitit-21, r=compiler-errors I suspect this is #112086 |
slightly more minimal (ordering is irrelevant) |
|
more reduced: mod a {
pub mod b {
pub mod c {}
}
}
use a::*;
use b::c;
use c as b;
fn main() {} |
matthiaskrgr
added
the
S-bug-has-test
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 29, 2024
resolve: mark it undetermined if single import is not has any bindings - Fixes rust-lang#124490 - Fixes rust-lang#125013 This issue arises from incorrect resolution updates, for example: ```rust mod a { pub mod b { pub mod c {} } } use a::*; use b::c; use c as b; fn main() {} ``` 1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`. 1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`. 2. Then, the `imported_module` for `use c as b` will be recorded. 2. In the second loop, `use b::c` will be processed again: 1. Firstly, it attempts to find the `path_res` for `(root, b)`. 2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator. 3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`. 4. Then define the binding `(root, c)` -> `root::a::b::c`. 3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency. In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding. r? `@petrochenkov`
fmease
added a commit
to fmease/rust
that referenced
this issue
Jun 4, 2024
resolve: mark it undetermined if single import is not has any bindings - Fixes rust-lang#124490 - Fixes rust-lang#125013 This issue arises from incorrect resolution updates, for example: ```rust mod a { pub mod b { pub mod c {} } } use a::*; use b::c; use c as b; fn main() {} ``` 1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`. 1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`. 2. Then, the `imported_module` for `use c as b` will be recorded. 2. In the second loop, `use b::c` will be processed again: 1. Firstly, it attempts to find the `path_res` for `(root, b)`. 2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator. 3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`. 4. Then define the binding `(root, c)` -> `root::a::b::c`. 3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency. In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding. r? `@petrochenkov`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 5, 2024
Rollup merge of rust-lang#124840 - bvanjoi:fix-124490, r=petrochenkov resolve: mark it undetermined if single import is not has any bindings - Fixes rust-lang#124490 - Fixes rust-lang#125013 This issue arises from incorrect resolution updates, for example: ```rust mod a { pub mod b { pub mod c {} } } use a::*; use b::c; use c as b; fn main() {} ``` 1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`. 1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`. 2. Then, the `imported_module` for `use c as b` will be recorded. 2. In the second loop, `use b::c` will be processed again: 1. Firstly, it attempts to find the `path_res` for `(root, b)`. 2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator. 3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`. 4. Then define the binding `(root, c)` -> `root::a::b::c`. 3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency. In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding. r? ``@petrochenkov``
|
Again, the original example still crashes. |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Jun 7, 2024
mark binding undetermined if target name exist and not obtained - Fixes rust-lang#124490 - Fixes rust-lang#125013 Following up on rust-lang#124840, I think handling only `target_bindings` is sufficient. r? `@petrochenkov`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 8, 2024
Rollup merge of rust-lang#126065 - bvanjoi:fix-124490, r=petrochenkov mark binding undetermined if target name exist and not obtained - Fixes rust-lang#124490 - Fixes rust-lang#125013 Following up on rust-lang#124840, I think handling only `target_bindings` is sufficient. r? `@petrochenkov`
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc -Zunstable-options --edition=2024Program output
The text was updated successfully, but these errors were encountered: