commit a8028abedbc768bce84ede60b2e8cda629e11c01
author Urgau <3616612+Urgau@users.noreply.github.com> Fri Jan 09 23:28:16 2026 +0100
committer GitHub <noreply@github.com> Fri Jan 09 23:28:16 2026 +0100
tree 635cbbcf1e16bca3173f5df3a5776ee8c5d4d0f5
parent 3bb7de6408fb8399102c43a105d54b221308e211
parent 7791bc22133cce1693b364f76e99416b50f4d348

Rollup merge of #150822 - fix-149981, r=@Kivooeo

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

Closes rust-lang/rust#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 :sob:.