FnDef tys can point to different monomorphic instances (with same DefId?)

[dkcumming]

Description

It appears that FnDef can point to different monomorphic instances. This can be observed through collecting all possible monomorphic instances for all functions (not just ones that will actually be called). This is done in collect_fn_calls with link_items_enabled.

Reproduction

LINK_ITEMS=1 ./run.sh panic_example.rs
This will generate and error from update_link_map line 372. This will show a chain of Stable MIR types that can be summarised as a Ty { id: 42, kind: RigidTy(FnDef (FnDef(DefId { id: 11, name: "std::ops::FnOnce::call_once" } ... points to two different monomorphised instances:

1. NormalSym("_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h0b6b3134fd4818cdE")
2. NormalSym("_ZN4core3ops8function6FnOnce9call_once17h86e2963be1a2fd6aE")

Which demangled to:

1. NormalSym("core_ops_function_FnOnce_call_once{{vtable.shim}}")
2. NormalSym("core_ops_function_FnOnce_call_once")

To avoid the error (but not the problem) and print out the full logs instead run
DEBUG=1 LINK_ITEMS=1 LINK_INST=1 ./run.sh panic_example.rs
And search for all lines containing std::ops::FnOnce::call_once that also have the line starting with Generating (regenerating lines are not interesting for the problem). This will show that the two colliding items are both ItemSource(1) which corresponds to ITEM. This cannot be found in a Terminator, and this is probably due to this being called as part of a different crate to do with panicking.

Solution / Discussion

More information will be needed to distinguish which item is being referred to, however exactly how to do this is unknown currently as we do not track calls across crate boundaries explicitly