Do not continue past `rustc_resolve` when encountering duplicated items by estebank · Pull Request #162831 · rust-lang/rust

estebank · 2026-09-15T22:14:30Z

Duplicated items cause lots of confusing knock down errors. This change side-steps some known ICEs, and reduces the verbosity of crates with duplicated items at the cost of not emitting every error that we could.

Noticed just how problematic these can be while looking at #160695, as #[derive]s are particularly prone to the kind of confusion these duplicates cause.

Fix #120873, fix #123690.

r? @petrochenkov

rustbot · 2026-09-16T02:55:56Z

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

Duplicated items cause lots of confusing knock down errors. This change side-steps some known ICEs, and reduces the verbosity of crates with duplicated items at the cost of not emitting every error that we could.

120873 -> `tests/ui/resolve/multiple_definitions_attribute_merging.rs` (already existing) 123690 -> `tests/ui/resolve/duplicated-enum-variant.rs` 155482 -> `tests/ui/resolve/duplicated-item-in-const-generics.rs` Added two cases from the report that still ICE.

rustbot · 2026-09-16T19:16:45Z

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.

estebank · 2026-09-16T21:22:50Z

CC @oli-obk as we spent a lot of time some years back removing Fatal.raise() as much as possible, and this is a partial walk-back.

petrochenkov · 2026-09-18T15:54:39Z

+                    // Duplicated types wreak havoc on other errors, like impls selecting the wrong
+                    // type causing wrong number of generic params and other assorted number of
+                    // irrelevant nonsense, so avoid advancing to the next compiler stage.
+                    self.raise_fatal_after_resolve = true;


Why is the flag set conditionally, depending on whether the old or new declaration is an import or not?
I'd expect no such condition, anything that can be defined can be imported as well.

Or if the problem is with types specifically, the condition could be ns == TypeNS or more specific based on old_binding.res().

View changes since the review

Changed. We silence fewer errors now by checking ns == TypeNS. The only knock down error in the suite that I'd like to get rid off caused by dupes is "missing method in impl" caused when the impl has a single method but the trait has two with the same name, but that is minor.

rust-bors · 2026-09-19T12:06:21Z

☔ The latest upstream changes (presumably #163002) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

rustbot assigned petrochenkov Sep 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Sep 15, 2026