-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Remove (useless) argument of entry_fn query #71648
Remove (useless) argument of entry_fn query #71648
Conversation
This should be fine because argument was asserted to always be LOCAL_CRATE. Moreover the query returns `LocalDefId` which makes it clear that this query is about the current local crate.
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @eddyb |
@@ -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 comment
The 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 comment
The reason will be displayed to describe this comment to others. Learn more.
I checked, no query have ()
as argument/key type yet, i think.
cc @rust-lang/compiler We could probably do this for all the queries that are local-crate analyses like "typeck everything" and "borrowck everything" etc., what do you think? |
@eddyb I have no objection. We originally included the crate because we wanted to be moving away from the idea of having a "local crate" that is being compiled -- but I think that's easy to change later. Also, there will always have to be some notion of "local crate", since some things -- like coherence rules -- depend on what the "current crate" is, although I imagine those things will always be associated with some def-id. |
I think it's simpler than that, the query system started out with |
@@ -178,7 +178,7 @@ fn exported_symbols_provider_local( | |||
.map(|(&def_id, &level)| (ExportedSymbol::NonGeneric(def_id), level)) | |||
.collect(); | |||
|
|||
if tcx.entry_fn(LOCAL_CRATE).is_some() { | |||
if tcx.entry_fn(()).is_some() { |
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 implements query::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:
if tcx.entry_fn().is_some() {
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 to entry_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.
/// 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 comment
The 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 None
and then all other crates just yield that None
?
☔ The latest upstream changes (presumably #71807) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from Triage: @marmeladema Hello, any updates on this PR? |
@Elinvynia it appears there is not really a consensus about what the prototype of such query should be. Possibilities are:
|
@marmeladema Ping from triage! This has merge conflicts now, and it seems the design discussion has stalled. Could you fix the merge conflicts so i can switch this back to S-waiting-on-review state? By the way, I think you could also open a topic on t-compiler in Zulip to push resolving the API design issue forward. |
I think this is the final goal. I'd be fine with merging the current PR with a |
r? @oli-obk |
@marmeladema any updates on this? |
I will try to modify the macro in order to be able to define queries without argument 👍 |
note from triage |
@marmeladema Ping from triage! I'm going to close this due to inactivity. Feel free to reopen or open a new PR when you get to continue working on this. Thanks! |
This should be fine because argument was asserted to always be
LOCAL_CRATE. Moreover the query returns
LocalDefId
which makesit clear that this query is about the current local crate.