Avoid prematurely choosing a glob import by mu001999 · Pull Request #153912 · rust-lang/rust

mu001999 · 2026-03-15T11:34:36Z

Use the following without introducing trait to explain:

mod a {
    pub use crate::x::y as x; // single import #1
}

mod b {
    pub mod x {
        pub mod y {}
    }
}

use a::x; // single import #2
use b::*; // glob import #3

fn main() {}

In current implementation, when #1 is first resolved, crate::x is temporarily taken from glob import #3 as crate::b::x. This happens because single_import_can_define_name will see that #2 cannot define x (because it depends on #1 and #1 is ignored) and then return false. Later, during finalization, crate::x in #1 resolves through single import #2 instead, which no longer matches the initially cached module crate::b::x and triggers the ICE.

I think the resolver should keep this unresolved because #2 may still define x to avoid prematurely choosing a glob import.

r? petrochenkov

… with current import

petrochenkov · 2026-03-16T11:14:25Z

This code is a minefield, it is known to not be correct, it makes assumptions that do not hold, and the whole thing needs to be rewritten together with some correctness proof.
So I have zero confidence that the change from this PR is correct either.

petrochenkov · 2026-03-16T11:15:10Z

Best I can do is to run crater on this and see what happens.
Although I'm not sure it's a good use of crater resources.
@bors try

Avoid prematurely choosing a glob import

petrochenkov · 2026-03-16T11:18:39Z

Glob imports that get selected first and then overwritten by single imports is something that is indeed done in the current system, even if it may be incorrect in corner cases, see e.g. the comments in select_glob_decl.

rust-bors · 2026-03-16T13:24:20Z

☀️ Try build successful (CI)
Build commit: b10dae3 (b10dae361a61486cfbdcd3aae3877ee17e00d192, parent: fe7294f8793d001bc3f9d197e7cdef6cdb46c15a)

petrochenkov · 2026-03-16T15:29:17Z

Okay, the crater queue doesn't seem to be large at the moment.
@craterbot check

craterbot · 2026-03-16T15:29:43Z

👌 Experiment pr-153912 created and queued.
🤖 Automatically detected try build b10dae3
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-03-19T02:18:05Z

🚧 Experiment pr-153912 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-03-21T01:19:45Z

🎉 Experiment pr-153912 is completed!
📊 4 regressed and 7 fixed (853200 total)
📊 4754 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-153912/retry-regressed-list.txt ↩

petrochenkov · 2026-03-21T06:09:45Z

No non-spurious regressions.
So my only concern now is that it can now accept more code that we may not want to accept.

mu001999 · 2026-03-21T08:23:23Z

it can now accept more code that we may not want to accept

IIUC, single imports will be selected finally. This change is in single_import_can_define_name, will only avoid choosing a glob import when meeting both single and glob imports. It won't affect the final result of the resolution. So when we do the final resolutions, we should still deny the code that we won't accept currently.

But I have to say that I still don't have a complete mental model of resolver yet.

petrochenkov · 2026-03-23T15:07:55Z

Okay, @bors r+

rust-bors · 2026-03-23T15:07:58Z

📌 Commit 5316bab has been approved by petrochenkov

It is now in the queue for this repository.

…rochenkov Avoid prematurely choosing a glob import Fixes rust-lang#153842 Use the following without introducing trait to explain: ```rust mod a { pub use crate::x::y as x; // single import rust-lang#1 } mod b { pub mod x { pub mod y {} } } use a::x; // single import rust-lang#2 use b::*; // glob import rust-lang#3 fn main() {} ``` In current implementation, when `rust-lang#1` is first resolved, `crate::x` is temporarily taken from glob import `rust-lang#3` as `crate::b::x`. This happens because `single_import_can_define_name` will see that `rust-lang#2` cannot define `x` (because it depends on `rust-lang#1` and `rust-lang#1` is ignored) and then return `false`. Later, during finalization, `crate::x` in `rust-lang#1` resolves through single import `rust-lang#2` instead, which no longer matches the initially cached module `crate::b::x` and triggers the ICE. I think the resolver should keep this unresolved because `rust-lang#2` may still define `x` to avoid prematurely choosing a glob import. r? petrochenkov

…uwer Rollup of 8 pull requests Successful merges: - #122668 (Add APIs for dealing with titlecase) - #153041 (Remove `ATTRIBUTE_ORDER`) - #153912 (Avoid prematurely choosing a glob import) - #154093 (const validity checking: do not recurse to references inside MaybeDangling) - #154257 (Revert eagerly normalize in generalize) - #154179 (tests/ui/async-await/gat-is-send-across-await.rs: New regression test) - #154224 (Remove more `BuiltinLintDiag` variants) - #154245 (Allow applying autodiff macros to trait functions.)

Avoid choosing a glob import if a single import could define the same…

5316bab

… with current import

rustbot assigned petrochenkov Mar 15, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 15, 2026

rust-bors bot pushed a commit that referenced this pull request Mar 16, 2026

Auto merge of #153912 - mu001999-contrib:fix-153842, r=<try>

b10dae3

Avoid prematurely choosing a glob import

This comment has been minimized.

Sign in to view

petrochenkov added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 16, 2026

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Mar 21, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 23, 2026

This was referenced Mar 23, 2026

Rollup of 9 pull requests #154268

Closed

Rollup of 8 pull requests #154273

Merged

rust-bors bot merged commit 924b911 into rust-lang:main Mar 24, 2026
12 checks passed

rustbot added this to the 1.96.0 milestone Mar 24, 2026

mu001999 deleted the fix-153842 branch March 24, 2026 08:49

Uh oh!

Conversation

mu001999 commented Mar 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Mar 16, 2026

Uh oh!

petrochenkov commented Mar 16, 2026

Uh oh!

This comment has been minimized.

petrochenkov commented Mar 16, 2026

Uh oh!

rust-bors bot commented Mar 16, 2026

Uh oh!

petrochenkov commented Mar 16, 2026

Uh oh!

craterbot commented Mar 16, 2026

Uh oh!

craterbot commented Mar 19, 2026

Uh oh!

craterbot commented Mar 21, 2026

Footnotes

Uh oh!

petrochenkov commented Mar 21, 2026

Uh oh!

mu001999 commented Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Mar 23, 2026

Uh oh!

rust-bors bot commented Mar 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mu001999 commented Mar 15, 2026 •

edited by rustbot

Loading

mu001999 commented Mar 21, 2026 •

edited

Loading