resolve: Factor out and document the glob binding overwriting logic #150502

petrochenkov · 2025-12-30T07:43:57Z

Also, avoid creating fresh name declarations and overwriting declarations in modules to update some fields in DeclData, when possible.
Instead, change the fields directly in DeclData using cells.

Unblocks #149195.

rustbot · 2025-12-30T07:44:02Z

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

petrochenkov · 2025-12-30T14:26:57Z

r? @yaahc maybe

yaahc

Still reviewing. I'm struggling to fully understand what this does and how it works. I might need a more in-depth explanation in order to feel comfortable approving but I'm not done reviewing this yet and plan to pick it up tomorrow so I'll let you know if I get stuck and need said help understanding.

View changes since this review

yaahc · 2026-01-05T23:17:50Z

compiler/rustc_resolve/src/imports.rs

+        // - A glob binding is overwritten by its clone after setting ambiguity in it.
+        //   FIXME: avoid this by removing `warn_ambiguity`, or by triggering glob re-fetch


confirming, this is the case with this PR right, not just before it?

Yes, previously these cases fell under a slightly different FIXME ("avoid this by putting NameBindingData::ambiguity under a cell and updating it in place").

yaahc · 2026-01-05T23:19:52Z

compiler/rustc_resolve/src/imports.rs

+        // - A glob binding is overwritten by its clone after setting ambiguity in it.
+        //   FIXME: avoid this by removing `warn_ambiguity`, or by triggering glob re-fetch
+        //   with the same binding in some way.
+        // - A glob binding is overwritten by a glob binding re-fetching an


struggling to understand what this means and how it interacts w/ the 55884 testcase

So suppose we have a glob g1 importing from module m1, and m1 has another glob g2 importing from module m2.
What this says is that when something in m2 changes, we are re-fetching not only g2, but g1 as well.
And g1 will re-fetch updated bindings from g2.
(And of course there also may be more than 2 globs referring to each other in this chain.)

I don't think this is the case that applies to the diagnostic change in tests/ui/imports/issue-55884-1.rs.
(The diagnostic change itself looks right, not sure why it wasn't reported before, maybe due to the deduplication from matches_previous_ambiguity_error, I'll check.)

The tests/ui/imports/issue-55884-1.rs change is not due to the deduplication.

Previously use m::S recorded the outdated resolution of m::S that is not yet ambiguous, and S {} used it.
(Import validation later observed the updated ambiguous resolution though, and reported an error.)
Now the resolution is updated in place, so S {} sees it too, and reports the ambiguity error on use too.

What this says is that when something in m2 changes, we are re-fetching not only g2, but g1 as well.

Aah, I think I understand, and when you say "when something in m2 changes" you mean "a macro gets expanded or an import gets materialized", not anything related to incremental compilation.

petrochenkov · 2026-01-06T04:20:46Z

FWIW, this was tested with crater as a part of #149195 (without the update in place part).

petrochenkov · 2026-01-06T11:55:46Z

(Now after #149681 this should be a bit simpler.)

yaahc

Alright, I think I understand and it seems to make sense.

I'm not 100% sure I understand this well enough to say "Would I be able to spot non-obvious side effects?"¹, but I'm also not confident there's anyone else on t-compiler that would be better suited to approve this so given it's already been cratered I'm going to go ahead and say r=me when conflicts are fixed.

View changes since this review

https://forge.rust-lang.org/compiler/reviews.html#checklist-for-reviewers ↩

instead of creating fresh bindings.

instead of overwriting bindings in modules.

Do not overwrite unless necessary, and combine both globs instead of losing the first one.

instead of creating fresh bindings, except in one case.

rustbot · 2026-01-08T08:03:15Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

petrochenkov · 2026-01-08T08:05:05Z

@bors r=yaahc

rust-bors · 2026-01-08T08:05:09Z

📌 Commit a251ae2 has been approved by yaahc

It is now in the queue for this repository.

matthiaskrgr · 2026-01-08T10:06:17Z

@bors rollup=never
for perf, also probably want to be able to bisect to this so lets not bury it in a rollup

rust-bors · 2026-01-10T08:56:09Z

☀️ Test successful - CI
Approved by: yaahc
Pushing 1b9ae9e to main...

github-actions · 2026-01-10T08:59:37Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 2b82e05 (parent) -> 1b9ae9e (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 1b9ae9eddcbd3b0105a0828e323c6db5f1e6ad0c --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

pr-check-1: 2033.6s -> 1668.6s (-18.0%)
aarch64-apple: 11818.5s -> 9927.4s (-16.0%)
x86_64-gnu-llvm-20-1: 4475.1s -> 3821.5s (-14.6%)
i686-gnu-2: 6146.6s -> 5277.0s (-14.1%)
x86_64-gnu-llvm-20-2: 5901.1s -> 5098.1s (-13.6%)
pr-check-2: 2576.4s -> 2263.1s (-12.2%)
x86_64-rust-for-linux: 3119.4s -> 2747.2s (-11.9%)
x86_64-gnu-llvm-20: 5162.0s -> 4554.9s (-11.8%)
x86_64-gnu-miri: 5020.5s -> 4447.2s (-11.4%)
aarch64-msvc-1: 6684.1s -> 7405.0s (+10.8%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-01-10T09:39:32Z

Finished benchmarking commit (1b9ae9e): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.2%	[2.2%, 2.2%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 474.298s -> 472.721s (-0.33%)
Artifact size: 391.29 MiB -> 391.33 MiB (0.01%)

rustbot assigned lcnr Dec 30, 2025

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 Dec 30, 2025

This comment has been minimized.

Sign in to view

petrochenkov force-pushed the overglob branch from c476e22 to 11cf5db Compare December 30, 2025 14:24

This comment has been minimized.

Sign in to view

rustbot assigned yaahc and unassigned lcnr Dec 30, 2025

petrochenkov mentioned this pull request Dec 30, 2025

resolve: Partially convert ambiguous_glob_imports lint into a hard error #149195

Open

This comment was marked as resolved.

Sign in to view

yaahc added the A-resolve Area: Name/path resolution done by `rustc_resolve` specifically label Jan 5, 2026

yaahc reviewed Jan 5, 2026

View reviewed changes

petrochenkov force-pushed the overglob branch from 11cf5db to d80f558 Compare January 6, 2026 11:54

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

yaahc approved these changes Jan 7, 2026

View reviewed changes

petrochenkov added 5 commits January 8, 2026 10:26

resolve: Factor out and document the glob binding overwriting logic

e454835

resolve: Update NameBindingData::warn_ambiguity in place

32cf3a9

instead of creating fresh bindings.

resolve: Update NameBindingData::vis in place

227e7bd

instead of overwriting bindings in modules.

resolve: Tweak overwriting with ambiguous globs

c237971

Do not overwrite unless necessary, and combine both globs instead of losing the first one.

resolve: Update NameBindingData::ambiguity in place

a251ae2

instead of creating fresh bindings, except in one case.

petrochenkov force-pushed the overglob branch from d80f558 to a251ae2 Compare January 8, 2026 08:03

rust-bors bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 8, 2026

rust-bors bot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 8, 2026

This comment has been minimized.

Sign in to view

rust-bors bot added the merged-by-bors This PR was explicitly merged by bors. label Jan 10, 2026

rust-bors bot merged commit 1b9ae9e into rust-lang:main Jan 10, 2026
12 checks passed

rustbot added this to the 1.94.0 milestone Jan 10, 2026

This was referenced Jan 10, 2026

resolve: Mark items under exported ambiguous imports as exported #150491

Open

resolve: Refactor away the side table decl_parent_modules #150877

Open

reddevilmidzy mentioned this pull request Jan 10, 2026

ICE: None != Some(DeclData .. #150929

Open

This was referenced Jan 10, 2026

ICE 'compiler/rustc_resolve/src/imports.rs:309:9: 'assertion left == right failed' #150928

Open

ICE: assertion failed: !deep_decl.is_glob_import() #150927

Open

		// - A glob binding is overwritten by its clone after setting ambiguity in it.
		// FIXME: avoid this by removing `warn_ambiguity`, or by triggering glob re-fetch

Uh oh!

resolve: Factor out and document the glob binding overwriting logic #150502

resolve: Factor out and document the glob binding overwriting logic #150502

Uh oh!

Conversation

petrochenkov commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 30, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

petrochenkov commented Dec 30, 2025

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

yaahc left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Jan 6, 2026

Uh oh!

This comment has been minimized.

petrochenkov commented Jan 6, 2026

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

yaahc left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

petrochenkov commented Jan 8, 2026

Uh oh!

rust-bors bot commented Jan 8, 2026

Uh oh!

matthiaskrgr commented Jan 8, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Jan 10, 2026

Uh oh!

Uh oh!

github-actions bot commented Jan 10, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented Jan 10, 2026

Overall result: no relevant changes - no action needed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

petrochenkov commented Dec 30, 2025 •

edited

Loading

yaahc left a comment •

edited by rustbot

Loading

yaahc left a comment •

edited by rustbot

Loading