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,

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.