-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove (useless) argument of entry_fn query #71648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -884,9 +884,9 @@ rustc_queries! { | |
desc { "looking up the foreign modules of a linked crate" } | ||
} | ||
|
||
/// Identifies the entry-point (e.g., the `main` function) for a given | ||
/// Identifies the entry-point (e.g., the `main` function) for the current | ||
/// crate, returning `None` if there is no entry point (such as for library crates). | ||
query entry_fn(_: CrateNum) -> Option<(LocalDefId, EntryFnType)> { | ||
query entry_fn(_: ()) -> Option<(LocalDefId, EntryFnType)> { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Won't this query only get executed once in the entire dependency tree? So if a lib crate calls the query, you get |
||
desc { "looking up the entry function of a crate" } | ||
} | ||
query plugin_registrar_fn(_: CrateNum) -> Option<DefId> { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,7 +6,7 @@ use crate::traits; | |
use crate::ty::fast_reject::SimplifiedType; | ||
use crate::ty::subst::{GenericArg, SubstsRef}; | ||
use crate::ty::{self, Ty, TyCtxt}; | ||
use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, LOCAL_CRATE}; | ||
use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, CRATE_DEF_INDEX, LOCAL_CRATE}; | ||
use rustc_query_system::query::DefaultCacheSelector; | ||
use rustc_span::symbol::Symbol; | ||
use rustc_span::{Span, DUMMY_SP}; | ||
|
@@ -25,6 +25,18 @@ pub trait Key { | |
fn default_span(&self, tcx: TyCtxt<'_>) -> Span; | ||
} | ||
|
||
impl Key for () { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wait, this is new? I thought there was precedent for this. I guess we can still go ahead with this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I checked, no query have |
||
type CacheSelector = DefaultCacheSelector; | ||
|
||
fn query_crate(&self) -> CrateNum { | ||
LOCAL_CRATE | ||
} | ||
|
||
fn default_span(&self, tcx: TyCtxt<'_>) -> Span { | ||
tcx.def_span(DefId::local(CRATE_DEF_INDEX)) | ||
} | ||
} | ||
|
||
impl<'tcx> Key for ty::InstanceDef<'tcx> { | ||
type CacheSelector = DefaultCacheSelector; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we give a name (
LocalCrate
) to the unit struct that implementsquery::Key
? Otherwise, it's not immediately clear to me what this line is doing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems like a good idea to me. @eddyb do you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's one way. But this is basically a nulary query.
If we tweaked the macros a bit we could write this instead:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go that route, we should rename the
entry_fn
query toentry_fn_local_crate
. Otherwise the same readability issues apply.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if adding an improved doc comment would suffice? It seems reasonable clear to me that the
entry_fn
computes, well, the entry function -- I guess the thing that is sort of non-obvious is the overall model where the root crate has an entry function, and it seems like that would be best explained in docs?In particular,
entry_fn_for_local_crate
(if we're going to use a long name, I'd prefer to make it read well...) seems to imply that other crates can have entry functions, which isn't really true?Anyway, a minor thing, but I guess it may become a more wide-spread convention either way.