Skip to content
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

Closed

Conversation

marmeladema
Copy link
Contributor

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.

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
Copy link
Collaborator

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 28, 2020
@marmeladema
Copy link
Contributor Author

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned matthewjasper Apr 28, 2020
@@ -25,6 +25,18 @@ pub trait Key {
fn default_span(&self, tcx: TyCtxt<'_>) -> Span;
}

impl Key for () {
Copy link
Member

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.

Copy link
Contributor Author

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.

@eddyb
Copy link
Member

eddyb commented Apr 28, 2020

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?

@nikomatsakis
Copy link
Contributor

@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.

@eddyb
Copy link
Member

eddyb commented Apr 28, 2020

I think it's simpler than that, the query system started out with DefId and CrateNum keys, and the cratenum from either of those was used to look up the providers. We only added CrateNum-less key types like Ty after that.

@@ -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() {
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Member

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() {

Copy link
Contributor

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.

Copy link
Contributor

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)> {
Copy link
Contributor

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?

@bors
Copy link
Contributor

bors commented May 3, 2020

☔ The latest upstream changes (presumably #71807) made this pull request unmergeable. Please resolve the merge conflicts.

@Elinvynia Elinvynia added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 20, 2020
@Elinvynia
Copy link
Contributor

Ping from Triage: @marmeladema Hello, any updates on this PR?

@Elinvynia Elinvynia added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 27, 2020
@marmeladema
Copy link
Contributor Author

@Elinvynia it appears there is not really a consensus about what the prototype of such query should be. Possibilities are:

  • Keep it as proposed in this PR with explicit unit struct as argument tcx.entry_fn(())
  • Use an empty struct and implement query::Key trait: tcx.entry_fn(LocalCrate)
  • Modify the query macros to be able to define queries without argument: tcx.entry_fn()

@Elinvynia Elinvynia added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 27, 2020
@Elinvynia Elinvynia added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2020
@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 23, 2020
@crlf0710
Copy link
Member

@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.

@crlf0710 crlf0710 removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 10, 2020
@crlf0710 crlf0710 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 10, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Jul 10, 2020

Modify the query macros to be able to define queries without argument: tcx.entry_fn()

I think this is the final goal. I'd be fine with merging the current PR with a LocalCrate ZST for the query argument and then doing the removal in a separate PR if that's preferrable to you. Otherwise, let's go full nullary query and allow queries to not have arguments at all right away in this PR.

@oli-obk
Copy link
Contributor

oli-obk commented Jul 10, 2020

r? @oli-obk

@rust-highfive rust-highfive assigned oli-obk and unassigned eddyb Jul 10, 2020
@Elinvynia Elinvynia added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 25, 2020
@Dylan-DPC-zz
Copy link

@marmeladema any updates on this?

@marmeladema
Copy link
Contributor Author

I will try to modify the macro in order to be able to define queries without argument 👍

@JohnCSimon
Copy link
Member

JohnCSimon commented Aug 25, 2020

note from triage
@marmeladema - this now has merge conflicts and hasn't seen any commits in a while. Thank you.

@crlf0710
Copy link
Member

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.