In the compiler, a DefId is used to lookup a single "definition" (type, method, const, etc.) somewhere in the code. It can refer to definitions in the crate currently being compiled or to definitions in other crates. There are quite a few places in the compiler which will only work if passed a local DefId--maybe they need to access the HIR for that definition, which is only available in the current crate--but accept DefId as a parameter. These places should use LocalDefId instead.
To resolve this issue, you need to find functions or methods that will panic if a DefId is not local. Such places should be calling DefId::expect_local and then working with the returned LocalDefId, but you are more likely to see older idioms (e.g., tcx.as_local_hir_id(def_id).unwrap()). Code like this should be refactored to take a LocalDefId instead of a DefId and their caller made responsible for asserting that a given DefId is local. The end goal is to move the call to expect_local as high up in the call graph as we can. If possible, it should be the first thing we do when executing a query like so, https://github.com/rust-lang/rust/blob/40158901d5c7e65b2fb5adc6ce186bc308274954/src/librustc_mir/const_eval/fn_queries.rs#L174
Ideally this would be done module-by-module so it can be reviewed more easily (not in a single, giant PR). See the last commit in #66132 for prior art.
This issue has been assigned to @marmeladema via this comment.
Is there a reason why the queries should keep using DefId instead of LocalDefId?
@lcnr For many queries, the result is encoded into a crate's metadata so it can be looked up while compiling other crates. For these queries, only the initial computation of the result of needs to be done in the local crate. Cross-crate invocations will look up the cached result via metadata.
However, queries that are not encoded into a crate's metadata are only accessible in the local crate. Such queries should indeed take a LocalDefId instead of a DefId.
I can try to take a look, its sounds easy enough and well constrained.
@rustbot assign @marmeladema
@eddyb @ecstatic-morse the last PR i had has landed. Do you see any other places where LocalDefId should be used?
There are some places that use HirId but are always owners, I think, which would allow using LocalDefId instead, but that doesn't (directly) count.
There might still be DefId which could be LocalDefId in smaller (or shorter-lived, I guess) context types, but I wouldn't know where to start looking for them.
Most helpful comment
@eddyb @ecstatic-morse the last PR i had has landed. Do you see any other places where
LocalDefIdshould be used?