[ICE]: `find_attr!` panics for `SyntheticCoroutineBody` (in Miri, related to rustc_no_writable)

[quiode]

Some time ago, I introduced some changes in Miri (rust-lang/miri#4988) that made it use the find_attr! macro. I then ran Miri with those changes on some crates and found a compiler panic. As the panic originates inside the find_attr! logic and not from Miri, I assume this is the right place to open the issue.

It seems that when the find_attr! is called on an external crate on a specific type of function, the logic does not handle it correctly. To be more precise, in decoder.rs in get_item_attrs:

 self.root
            .tables
            .attributes
            .get(self, id)
            .unwrap_or_else(|| {
                // Structure and variant constructors don't have any attributes encoded for them,
                // but we assume that someone passing a constructor ID actually wants to look at
                // the attributes on the corresponding struct or variant.
                let def_key = self.def_key(id);
                assert_eq!(def_key.disambiguated_data.data, DefPathData::Ctor);
                let parent_id = def_key.parent.expect("no parent for a constructor");
                self.root
                    .tables
                    .attributes
                    .get(self, parent_id)
                    .expect("no encoded attributes for a structure or variant")
            })
            .decode((self, tcx))

the assert_eq fails. It seems like this function only expects this unwrap to happen for constructors, but apparently it also happens for SyntheticCoroutineBody.

Initially, I found this panic in the agent-client-protocol crate, version 0.12.1 using the test agent-client-protocol::jsonrpc_advanced test_bidirectional_communication when running Miri with tree borrows and implicit writes enabled on it. But since then also many more crates can show this error. I could also replicate it here inside the Miri test suite: quiode@dd72b0b.

Error output

thread 'rustc' ($TID) panicked at /rustc-dev//compiler/rustc_metadata/src/rmeta/decoder.rs:LL:CC:
assertion `left == right` failed
  left: SyntheticCoroutineBody
 right: Ctor
stack backtrace:

error: the compiler unexpectedly panicked. This is a bug

query stack during panic:
#0 [attrs_for_def] collecting attributes of `closure_ice_lib::line_sink::{closure#0}::{synthetic#0}`
end of query stack

Miri caused an ICE during evaluation. Here's the interpreter backtrace at the time of the panic:
  --> closure-ice-lib/src/lib.rs:LL:CC
   |

(RUST_BACKTRACE=1 produces the same output)

[quiode]

I already mentioned this to @JoJoDeveloping but it would be nice of you could have a look at it @RalfJung

[RalfJung]

Uh... I don't know much about this part of the compiler, sorry. Looks like it's going to be a bit more work to preserve this attribute cross-crate. OTOH we do already successfully use it cross-crate, after all we set the attribute in std and that seems to work fine? So maybe it's not about this being cross crate but find_attr! just not supporting all possible DefId that represent functions?

Cc @oli-obk @jdonszelmann

[oli-obk]

Yea looks like we don't encode any attrs for SyntheticCoroutineBody, as you can't write any attrs on them. instead loading the parent's attrs like for ctors makes sense in case this is actually how attrs behave in the local crate, too. Otherwise just yielding an empty set seems fine?

[scrabsha]

I hit this last week while working on reflection. Oli and I decided it was ok to (temporarily) allow AnonConst in addition to CTor in the assertion, and it worked! However, I rebased my work over the latest main this morning, and now the expect at the end of the snippet panics the compiler.

[RalfJung]

Would the fix just be "if this is SyntheticCoroutineBody then return empty"?