ICE:assertion failed: import.imported_module.get().is_none()
#125013
Labels
A-resolve
Area: Name resolution
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
jieyouxu
added
A-resolve
|
Minimized: mod a {
pub mod b {
pub mod c {
pub trait D {}
}
}
}
use a::*;
use e as b;
use b::c::D as e;
fn main() { } |
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``
|
😅 while the "minimized" example is fixed, my original finding still crashes 🙃 cc @bvanjoi in case you would like to have a look again |
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`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This crashes with every edition except 2015 🤔
snippet:
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: