[Bug]: Maker panics if the trait from `std` is requested via `ctx.ast().item()` about marker HOT 2 OPEN

The problem occurs because the code tries to look up the definition of the item in HIR, but that item comes from a foreign crate.

When the TraitRef's ItemId is created here

So this results in an invalid rustc_hir::hir::ItemId. You'll get a panic even if you try to debug-print this ID.

I'm not sure what the best solution here should be. Maybe the to_item_id(ItemId) -> hir::ItemId method should check if layout.krate is not a local crate. I suppose there is a special sentinel value for krate that identifies it as the current crate. Then if the given item is not from the current crate it should return None.

But how could users query the info about which trait is implemented? Maybe if there was at least the path to the implemented trait in the TraitRef that would allow to check the syntactic path to the trait.

from marker.

Ahh, I think the actual problem is the type. TraitRef should hold a TyDefId instead, and Marker should probably have a function to convert the TyDefId into an ItemId if the item is available.

Thinking about it, this will not resolve all issues though 🤔 Users can still retrieve ItemIds when AstPaths are resolved. So this case definitely need to be handled on Marker's side.

Rustc splits these IDs into a general DefId which can be used across crate boundaries, but is not guaranteed to have an ast item, and a LocalDefId which is only defined for items from the current crate, where an ast representation exists. I wonder if it would make sense to adapt a similar model 🤔

from marker.