Hey @oli-obk , what intuition should a developer use to determine which of these two methods they are supposed to call in a given context? How can I know if the query-based lcx.tcx.$METHOD is the appropriate thing to call?

Is it a matter of "If you see an ICE with 'forcing query with already existing DepNode', then you are doing it wrong" ? Unfortunately the error output I see on #83085 doesn't clearly point one to this code, so I don't know how someone would track it down...

I don't think anyone should be calling this query. It was wrong of me to implement the traits that allowed ConstValue (an argument to the query), to be used in query arguments, as it can produce equal stable hashes for things that are not identical via PartialEq (in fact, this is very easy to cause, just by allocating two different AllocIds for the same Allocation, as all AllocIds are stable-hashed by the allocation they refer to).

But we have no way to avoid it from pretty printing at present, because that's implemented in rustc_middle while the query provider is in rustc_const_eval (which depends on rustc_middle).

But we have no way to avoid it from pretty printing at present, because that's implemented in rustc_middle while the query provider is in rustc_const_eval (which depends on rustc_middle).

Other cases like this are typically addressed by non-query dyn Traits or function pointers, rather than queries.

We don't really have a good place/system to add such function pointers to TyCtxt yet. I could look into making it part of the whole provider scheme.

If that's desirable, I will do that, but this PR should be landed quickly so we can have a small patch to beta, instead of a larger change (even if benign)

We don't really have a good place/system to add such function pointers to TyCtxt yet.

Well, lint_store and formerly cstore lived right in GlobalCtxt.
This PR seems fine for backport, though.