Fix for ICE: eii: fn / macro rules None in find_attr() #150822

jdonszelmann · 2026-01-08T18:30:46Z

This used to ICE:

macro_rules! foo_impl {}
#[eii]
fn foo_impl() {}

#[eii] generates a macro (called foo_impl) and a default impl. So the partial expansion used to roughly look like the following:

macro_rules! foo_impl {} // actually resolves here

extern "Rust" {
    fn foo_impl();
}

#[eii_extern_target(foo_impl)]
macro foo_impl {
    () => {};
}

const _: () = {
    #[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above
    fn foo_impl() {}
};

Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36

So instead of resolving to the macrov2, we resolve the macrov1 named the same thing.

A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause.

To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like:

macro_rules! foo_impl {}

extern "Rust" {
    fn foo_impl(); // resolves to here now!!!
}

#[eii_extern_target(foo_impl)]
macro foo_impl {
    () => {};
}

const _: () = {
    #[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function. 
    fn foo_impl() {}
};

The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope.

We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane.

Finally, I lied a tiny bit because the above partial expansion doesn't actually work.

extern "Rust" {
    fn foo_impl(); // not to here
}

const _: () = {
    #[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself
    fn foo_impl() {} // <--- so to here
};

So the last few commits change the expansion to actually be this:

macro_rules! foo_impl {}

extern "Rust" {
    fn foo_impl(); // resolves to here now!!!
}

#[eii_extern_target(foo_impl)]
macro foo_impl {
    () => {};
}

const _: () = {
    mod dflt { // necessary, otherwise `super` doesn't work
        use super::*;
        #[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item.
        fn foo_impl() {}
    }
};

I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.

rustbot · 2026-01-08T18:30:51Z

r? @chenyukang

rustbot has assigned @chenyukang.
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

Kivooeo · 2026-01-08T22:32:46Z

compiler/rustc_codegen_ssa/src/codegen_attrs.rs

+                                extern_item
+                            }
+                            EiiImplResolution::Known(decl, _) => decl.eii_extern_target,
+                            EiiImplResolution::Error(_eg) => continue,


was this _eg a leftover from some logic here? i see the same pattern in many places (where you match for error), could you explain this a little, cuz it's not really obvious to me why we want to skip errors

also it would be nice to clean up this unusable variables a bit

no, it's just a good reminder that if we get there, we're allowed to skip it because an error is already emitted.
I tried to separate out the logic of this, but I don't think I prefer it. A method on EiiImplResolution would make sense, but we need the tcx which we don't have in rustc_hir, so the signature would be super awkward, requiring an FnOnce to be passed in or something to get the attributes. I really did consider it but I personally believe this is nicest

And yea, the eg is technically never used. I just wanted to make sure for myself I wouldn't accidentally skip EIIs without having a very good reason for it

yeah, that makes sense, will continue looking into this pr, not sure how much time it will take, i hopefully might finish it later today (it's a jan 9th and it's a bit late at my place)

i dit a quick glance a first 4-5 commits, looks fine overall

thanks kivoo! You're amazing

Kivooeo · 2026-01-08T23:06:19Z

r? me

… go unnoticed

rustbot · 2026-01-09T13:30:42Z

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.

jdonszelmann · 2026-01-09T13:31:06Z

@rustbot review (rebased on the other PR)

compiler/rustc_builtin_macros/src/eii.rs

Kivooeo · 2026-01-09T14:19:15Z

this all looks good to me, i'm in pretty much favour of how the eii is now resolving with this changes

let's wait on what ci thinks on this matter

jdonszelmann · 2026-01-09T15:23:17Z

@bors r=@Kivooeo

rust-bors · 2026-01-09T15:23:22Z

📌 Commit 7791bc2 has been approved by @Kivooeo

It is now in the queue for this repository.

Kivooeo · 2026-01-09T15:24:47Z

thanks for working on it :)

@ghost

Rollup of 9 pull requests Successful merges: - #149318 (Implement partial_sort_unstable for slice) - #150805 (Fix ICE in inline always warning emission.) - #150822 (Fix for ICE: eii: fn / macro rules None in find_attr()) - #150853 (std: sys: fs: uefi: Implement File::read) - #150855 (std: sys: fs: uefi: Implement File::tell) - #150881 (Fix std::fs::copy on WASI by setting proper OpenOptions flags) - #150891 (Fix a trivial typo in def_id.rs) - #150892 (Don't check `[mentions]` paths in submodules from tidy) - #150894 (cg_llvm: add a pause to make comment less confusing) r? @ghost

@Kivooeo

Rollup merge of #150822 - fix-149981, r=@Kivooeo Fix for ICE: eii: fn / macro rules None in find_attr() Closes #149981 This used to ICE: ```rust macro_rules! foo_impl {} #[eii] fn foo_impl() {} ``` `#[eii]` generates a macro (called `foo_impl`) and a default impl. So the partial expansion used to roughly look like the following: ```rust macro_rules! foo_impl {} // actually resolves here extern "Rust" { fn foo_impl(); } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { #[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above fn foo_impl() {} }; ``` Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36 So instead of resolving to the macrov2, we resolve the macrov1 named the same thing. A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause. To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like: ```rust macro_rules! foo_impl {} extern "Rust" { fn foo_impl(); // resolves to here now!!! } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { #[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function. fn foo_impl() {} }; ``` The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope. We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane. Finally, I lied a tiny bit because the above partial expansion doesn't actually work. ```rust extern "Rust" { fn foo_impl(); // not to here } const _: () = { #[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself fn foo_impl() {} // <--- so to here }; ``` So the last few commits change the expansion to actually be this: ```rust macro_rules! foo_impl {} extern "Rust" { fn foo_impl(); // resolves to here now!!! } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { mod dflt { // necessary, otherwise `super` doesn't work use super::*; #[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item. fn foo_impl() {} } }; ``` I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.

rustbot assigned chenyukang Jan 8, 2026

rustbot added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Jan 8, 2026

This comment has been minimized.

Sign in to view

jdonszelmann force-pushed the fix-149981 branch from 5107b80 to b56c43f Compare January 8, 2026 21:05

This comment has been minimized.

Sign in to view

Kivooeo reviewed Jan 8, 2026

View reviewed changes

rustbot assigned Kivooeo and unassigned chenyukang Jan 8, 2026

jdonszelmann force-pushed the fix-149981 branch from b56c43f to 7dcaba2 Compare January 8, 2026 23:26

jdonszelmann added 6 commits January 9, 2026 09:29

add test for 149981

3c8265a

turn panics into span_delayed_bug to make sure this pattern doesn't…

5e5c724

… go unnoticed

dont resolve defaults anymore, store foreign item defid instead of macro

e3cff18

fix up diagnostics referring to the right items

5ddda0c

trick with super imports that fixes nameres in anonymous modules

52b3ac4

mark ICE regression test as fixed

7791bc2

jdonszelmann force-pushed the fix-149981 branch from 7dcaba2 to 7791bc2 Compare January 9, 2026 13:30

Kivooeo reviewed Jan 9, 2026

View reviewed changes

compiler/rustc_builtin_macros/src/eii.rs Show resolved Hide resolved

Kivooeo reviewed Jan 9, 2026

View reviewed changes

compiler/rustc_builtin_macros/src/eii.rs Show resolved Hide resolved

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-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jan 9, 2026

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

Urgau mentioned this pull request Jan 9, 2026

Rollup of 9 pull requests #150900

Merged

jdonszelmann mentioned this pull request Jan 10, 2026

Simplify #[eii] macro using methods on ecx #150906

Open

rust-bors bot merged commit a8028ab into rust-lang:main Jan 10, 2026
11 checks passed

rustbot added this to the 1.94.0 milestone Jan 10, 2026

Uh oh!

Fix for ICE: eii: fn / macro rules None in find_attr() #150822

Fix for ICE: eii: fn / macro rules None in find_attr() #150822

Conversation

jdonszelmann commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Kivooeo Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jan 8, 2026 • 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 Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Kivooeo Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Kivooeo commented Jan 8, 2026

Uh oh!

rustbot commented Jan 9, 2026

Uh oh!

jdonszelmann commented Jan 9, 2026

Uh oh!

Uh oh!

Uh oh!

Kivooeo commented Jan 9, 2026

Uh oh!

jdonszelmann commented Jan 9, 2026

Uh oh!

rust-bors bot commented Jan 9, 2026

Uh oh!

Kivooeo commented Jan 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jdonszelmann commented Jan 8, 2026 •

edited

Loading

jdonszelmann Jan 8, 2026 •

edited

Loading