-
Couldn't load subscription status.
- Fork 13.9k
Description
In working on #44142 I've come across the need/desire a few times to have "always dirty" nodes that are always recomputed at the base of the dependency graph. One example of this is handling today's extern_mod_stmt_cnum method.
Today there's a method CrateStore::extern_mod_stmt_cnum, but as part of #41417 we want to move this to a query. That's relatively simple but what's actually happening here I think is a bit more subtle in terms of dependencies. This query will take the ID of an extern crate statement and return the CrateNum that it loaded. This happens very early in the compiler when we're loading crates and it's basically "however CrateStore is implemented picks these numbers".
Right now, on my currently unmerged branch, the implementation looks like this:
extern_mod_stmt_cnum: |tcx, id| {
let id = tcx.hir.definitions().find_node_for_hir_id(id);
tcx.sess.cstore.extern_mod_stmt_cnum_untracked(id)
},So in other words this is just defining a query that doesn't actually have any dependencies! The extern_mod_stmt_cnum_untracked method just reaches into the internals of CStore and plucks a CrateNum seemingly out of thin air, returning it.
Ideally I think what we'll want here is a way of saying that queries like this need to be computed 100% of the time to determine if they're red or green. Typically they'll instantly turn green again which'll allow us to have lots of cache hits, but I'm worried about assumign they're always green because they have no inputs.
I believe this is a similar-ish issue to many of the maps in #44137 as well. For all the maps calculated in resolve then then hidden behind a query in TyCtxt those nodes don't actually have any dependencies, they're just reading internal tables. We should always rerun the query though to ensure that it is properly tracked!