Fixed ICE for EII with multiple defaults due to duplicate definition in nameres#150102

jdonszelmann · 2025-12-17T17:12:38Z

r? @jieyouxu (since you looked at the other one)

Previously a fix was proposed by @SATVIKsynopsis which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.

Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.

Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.

The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.

Thanks to @SATVIKsynopsis for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to @yaahc for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3

The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

Co-authored-by: SATVIKsynopsis <futureiitianisme@gmail.com>

SATVIKsynopsis · 2025-12-17T17:20:40Z

Thanks for the detailed explanation. that makes a lot of sense.
Glad the root cause is clearer now, and happy the tests were useful.

Kivooeo

This change replaces panic with span_delayed_bug, which seems like a good improvement based on the research Jana shared. I don’t foresee any issues from my side

feel free r=me on this

View changes since this review

jdonszelmann · 2025-12-17T23:27:36Z

@bors r=Kivooeo

bors · 2025-12-17T23:27:39Z

📌 Commit 08b7d34 has been approved by Kivooeo

It is now in the queue for this repository.

Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? `@jieyouxu` (since you looked at the other one) Fixes rust-lang#149982 Previously a [fix was proposed](rust-lang#149985) by `@SATVIKsynopsis` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to `@SATVIKsynopsis` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to `@yaahc` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? ``@jieyouxu`` (since you looked at the other one) Fixes rust-lang#149982 Previously a [fix was proposed](rust-lang#149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

…uwer Rollup of 5 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) r? `@ghost` `@rustbot` modify labels: rollup

Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? `@jieyouxu` (since you looked at the other one) Fixes #149982 Previously a [fix was proposed](#149985) by `@SATVIKsynopsis` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to `@SATVIKsynopsis` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to `@yaahc` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

bors · 2025-12-18T08:43:55Z

⌛ Testing commit 08b7d34 with merge 380d3a1...

bors · 2025-12-18T08:56:27Z

💔 Test failed - checks-actions

…uwer Rollup of 5 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) r? `@ghost` `@rustbot` modify labels: rollup

JonathanBrouwer · 2025-12-18T09:54:28Z

@bors retry (Spurious)

rust-log-analyzer · 2025-12-18T10:11:50Z

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)


#1 [internal] booting buildkit
#1 pulling image ghcr.io/rust-lang/buildkit:buildx-stable-1
#1 pulling image ghcr.io/rust-lang/buildkit:buildx-stable-1 15.1s done
#1 ERROR: Error response from daemon: Head "https://ghcr.io/v2/rust-lang/buildkit/manifests/buildx-stable-1": Get "https://ghcr.io/token?account=rust-lang&scope=repository%3Arust-lang%2Fbuildkit%3Apull&service=ghcr.io": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
------
 > [internal] booting buildkit:
------
ERROR: failed to build: Error response from daemon: Head "https://ghcr.io/v2/rust-lang/buildkit/manifests/buildx-stable-1": Get "https://ghcr.io/token?account=rust-lang&scope=repository%3Arust-lang%2Fbuildkit%3Apull&service=ghcr.io": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Command failed. Attempt 2/5:
#0 building with "elastic_williams" instance using docker-container driver

#1 [internal] booting buildkit
#1 pulling image ghcr.io/rust-lang/buildkit:buildx-stable-1
---
36c2692d9efd: Retrying in 3 seconds
36c2692d9efd: Retrying in 2 seconds
36c2692d9efd: Retrying in 1 second
36c2692d9efd: Pushed
Head "https://ghcr.io/v2/rust-lang/rust-ci/blobs/sha256:a38eab7450002b16e68075d089f670b86756adc594338543eb2634413e5bbf14": dial tcp 140.82.116.33:443: i/o timeout
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"
echo "disk usage:"
df -h
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}

…uwer Rollup of 5 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) r? `@ghost` `@rustbot` modify labels: rollup

jdonszelmann · 2025-12-18T11:20:41Z

spurious again hehe

jdonszelmann · 2025-12-18T11:20:45Z

@bors r+ rollup

bors · 2025-12-18T11:20:47Z

💡 This pull request was already approved, no need to approve it again.

bors · 2025-12-18T11:20:48Z

📌 Commit 08b7d34 has been approved by jdonszelmann

It is now in the queue for this repository.

bors · 2025-12-18T11:20:49Z

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

jdonszelmann · 2025-12-18T11:21:09Z

@bors r-
@bors r=Kivooeo

bors · 2025-12-18T11:21:13Z

📌 Commit 08b7d34 has been approved by Kivooeo

It is now in the queue for this repository.

bors · 2025-12-18T11:21:14Z

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

…uwer Rollup of 5 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) r? `@ghost` `@rustbot` modify labels: rollup

Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? `@jieyouxu` (since you looked at the other one) Fixes rust-lang#149982 Previously a [fix was proposed](rust-lang#149985) by `@SATVIKsynopsis` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to `@SATVIKsynopsis` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to `@yaahc` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

…uwer Rollup of 11 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #149925 (`cfg_select!`: parse unused branches) - #150022 (Generate macro expansion for rust compiler crates docs) - #150024 (Support recursive delegation) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) - #150124 (unstable.rs: fix typos in comments (implementatble -> implementable)) - #150125 (Port `#[rustc_lint_opt_deny_field_access]` to attribute parser) - #150126 (Subtree sync for rustc_codegen_cranelift) Failed merges: - #150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers) r? `@ghost` `@rustbot` modify labels: rollup

…uwer Rollup of 12 pull requests Successful merges: - #145933 (Expand `str_as_str` to more types) - #148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - #149925 (`cfg_select!`: parse unused branches) - #149952 (Suggest struct pattern when destructuring Range with .. syntax) - #150022 (Generate macro expansion for rust compiler crates docs) - #150024 (Support recursive delegation) - #150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - #150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - #150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) - #150124 (unstable.rs: fix typos in comments (implementatble -> implementable)) - #150125 (Port `#[rustc_lint_opt_deny_field_access]` to attribute parser) - #150126 (Subtree sync for rustc_codegen_cranelift) Failed merges: - #150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #150102 - jdonszelmann:fix-149982, r=Kivooeo Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? ``@jieyouxu`` (since you looked at the other one) Fixes #149982 Previously a [fix was proposed](#149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)

…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#145933 (Expand `str_as_str` to more types) - rust-lang/rust#148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - rust-lang/rust#149925 (`cfg_select!`: parse unused branches) - rust-lang/rust#149952 (Suggest struct pattern when destructuring Range with .. syntax) - rust-lang/rust#150022 (Generate macro expansion for rust compiler crates docs) - rust-lang/rust#150024 (Support recursive delegation) - rust-lang/rust#150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - rust-lang/rust#150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - rust-lang/rust#150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) - rust-lang/rust#150124 (unstable.rs: fix typos in comments (implementatble -> implementable)) - rust-lang/rust#150125 (Port `#[rustc_lint_opt_deny_field_access]` to attribute parser) - rust-lang/rust#150126 (Subtree sync for rustc_codegen_cranelift) Failed merges: - rust-lang/rust#150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers) r? `@ghost` `@rustbot` modify labels: rollup

jdonszelmann and others added 3 commits December 17, 2025 18:02

test for duplicate default eii ICE 149985

bd137df

Co-authored-by: SATVIKsynopsis <futureiitianisme@gmail.com>

turn panic into span_delayed_bug

1cd7cb1

another related case that deserved a test

08b7d34

rustbot assigned jieyouxu Dec 17, 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 17, 2025

jdonszelmann mentioned this pull request Dec 17, 2025

fixed ICE for more than one eii implementations #149985

Closed

Kivooeo approved these changes Dec 17, 2025

View reviewed changes

bors 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 Dec 17, 2025

jieyouxu assigned Kivooeo and unassigned jieyouxu Dec 17, 2025

JonathanBrouwer mentioned this pull request Dec 18, 2025

Rollup of 5 pull requests #150118

Closed

Zalathar mentioned this pull request Dec 18, 2025

Rollup of 5 pull requests #150119

Closed

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

bors 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 Dec 18, 2025

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 18, 2025

bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 18, 2025

JonathanBrouwer mentioned this pull request Dec 18, 2025

Rollup of 11 pull requests #150132

Closed

JonathanBrouwer mentioned this pull request Dec 18, 2025

Rollup of 12 pull requests #150135

Merged

bors merged commit 4c9451b into rust-lang:main Dec 18, 2025
11 of 12 checks passed

rustbot added this to the 1.94.0 milestone Dec 18, 2025

github-actions bot mentioned this pull request Dec 23, 2025

Toolchain upgrade to nightly-2026-02-07 flux-rs/flux#1345

Open

Uh oh!

Conversation

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jdonszelmann commented Dec 17, 2025

Uh oh!

bors commented Dec 17, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

JonathanBrouwer commented Dec 18, 2025

Uh oh!

rust-log-analyzer commented Dec 18, 2025

Uh oh!

jdonszelmann commented Dec 18, 2025

Uh oh!

jdonszelmann commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

jdonszelmann commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

jdonszelmann commented Dec 17, 2025 •

edited

Loading

SATVIKsynopsis commented Dec 17, 2025 •

edited

Loading

Kivooeo left a comment •

edited

Loading