incr.comp.: Refactor in_scope_traits query to take DefId instead of HirId as query-key

[michaelwoerister]

It must be possible for all "input" queries to reconstruct their query-key from their DepNode. The easiest way to accomplish this is to make the query-key a DefId.

The in_scope_traits query violates this condition at the moment. A simple way to fix this would be to make it a two-level map: The query returns a per-item map that is indexed by ItemLocalId. The query-key would be the HirId::owner.

cc @alexcrichton @nikomatsakis

[alexcrichton]

Oh is HirId not a suitable key for queries? Apologies if I mistakenly thought it was!

There's a few other queries that use HirId right now as well, and will those need to be fixed as well?

[michaelwoerister]

Well, let's say DefId is better because in that case we can reconstruct the query-key from the DepNode. If it's really needed we could provide that same support for HirId, but that would mean that we have to always build a Fingerprint -> HirId table during HIR lowering (we already do something like that for DefPathHash -> DefId).

[alexcrichton]

I took a slightly different approach in #44435 which just blanket converts to DefId, but let me know if that's in error! (there was quite a few new queries using HirId which also needed to change and it didn't seem so obvious for a two-level cache)

[michaelwoerister]

See #44435 (comment). I have not yet looked at the other queries that use HirId as key.