-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Description
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,
is_const_impl_raw: |tcx, def_id| is_const_impl_raw(tcx, def_id.expect_local()), |
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.
Activity
lcnr commentedon Apr 6, 2020
Is there a reason why the queries should keep using
DefId
instead ofLocalDefId
?ecstatic-morse commentedon Apr 6, 2020
@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 aDefId
.marmeladema commentedon Apr 7, 2020
I can try to take a look, its sounds easy enough and well constrained.
Dylan-DPC-zz commentedon Apr 7, 2020
@rustbot assign @marmeladema
impl Into<DefId>
for query methods onTyCtxt
#70961Auto merge of rust-lang#70909 - marmeladema:issue70853/librustc_hir-l…
LocalDefId
where possible in hir::map module #709868 remaining items
Rollup merge of rust-lang#71292 - marmeladema:queries-local-def-id, r…
Auto merge of rust-lang#71292 - marmeladema:queries-local-def-id, r=e…
marmeladema commentedon Apr 28, 2020
@eddyb @ecstatic-morse the last PR i had has landed. Do you see any other places where
LocalDefId
should be used?eddyb commentedon Apr 28, 2020
There are some places that use
HirId
but are always owners, I think, which would allow usingLocalDefId
instead, but that doesn't (directly) count.There might still be
DefId
which could beLocalDefId
in smaller (or shorter-lived, I guess) context types, but I wouldn't know where to start looking for them.LocalDefId
and fix docs #72096DefId
s withLocalDefId
#73796Rollup merge of rust-lang#73796 - lcnr:LocalDefId, r=matthewjasper
Rollup merge of rust-lang#73796 - lcnr:LocalDefId, r=matthewjasper
Rollup merge of rust-lang#73796 - lcnr:LocalDefId, r=matthewjasper
torhovland commentedon Nov 11, 2021
Looks like this issue can be closed?