Replace DefId with LocalDefId where possible
#70853
Comments
ecstatic-morse
added
E-easy
|
Is there a reason why the queries should keep using |
|
@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 |
|
I can try to take a look, its sounds easy enough and well constrained. |
|
@rustbot assign @marmeladema |
…ocal-def-id, r=eddyb librustc_hir: return LocalDefId instead of DefId in local_def_id Its a first try to remove a few calls to `expect_local` and use `LocalDefId` instead of `DefId` where possible for rust-lang#70853 This adds some calls to `.to_def_id()` to get a `DefId` back when needed. I don't know if I should push `LocalDefId` even further and change, for example, `Res::Def` to accept a `LocalDefId` instead of a `DefId` as second argument. cc @ecstatic-morse
…e-local-def-id, r=eddyb rustc_middle: return `LocalDefId` where possible in hir::map module This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`: * opt_local_def_id_from_node_id * opt_local_def_id * body_owner_def_id * local_def_id_from_node_id * get_parent_id This is another step in the right direction for rust-lang#70853 This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for rust-lang#70956 or rust-lang#70961 (or some other form it) to land first.
…dle-local-def-id, r=eddyb rustc_middle: return `LocalDefId` where possible in hir::map module This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`: * opt_local_def_id_from_node_id * opt_local_def_id * body_owner_def_id * local_def_id_from_node_id * get_parent_id This is another step in the right direction for rust-lang#70853 This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for rust-lang#70956 or rust-lang#70961 (or some other form it) to land first.
Take `impl Into<DefId>` for query methods on `TyCtxt` Alternative implementation of rust-lang#70956. cc rust-lang#70853.
…e-local-def-id-2, r=eddyb Simplify `local_def_id` and `as_local_hir_id` See rust-lang#70853
…=eddyb Convert more queries to use `LocalDefId` This PR is based on commits in rust-lang#71215 and should partially solve rust-lang#70853
…ddyb Convert more queries to use `LocalDefId` This PR is based on commits in rust-lang#71215 and should partially solve rust-lang#70853
|
@eddyb @ecstatic-morse the last PR i had has landed. Do you see any other places where |
|
There are some places that use There might still be |
replace more `DefId`s with `LocalDefId` part of rust-lang#70853
replace more `DefId`s with `LocalDefId` part of rust-lang#70853
replace more `DefId`s with `LocalDefId` part of rust-lang#70853
|
Looks like this issue can be closed? |
In the compiler, a
DefIdis 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 localDefId--maybe they need to access the HIR for that definition, which is only available in the current crate--but acceptDefIdas a parameter. These places should useLocalDefIdinstead.To resolve this issue, you need to find functions or methods that will panic if a
DefIdis not local. Such places should be callingDefId::expect_localand then working with the returnedLocalDefId, 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 aLocalDefIdinstead of aDefIdand their caller made responsible for asserting that a givenDefIdis local. The end goal is to move the call toexpect_localas 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,rust/src/librustc_mir/const_eval/fn_queries.rs
Line 174 in 4015890
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.
The text was updated successfully, but these errors were encountered: