Skip to content

Move name resolution logic to a dedicated file #95405

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Merged
merged 11 commits into from
Apr 13, 2022
Merged

Move name resolution logic to a dedicated file #95405

merged 11 commits into from
Apr 13, 2022

Conversation

cjgillot
Copy link
Contributor

The code resolution logic from an Ident is scattered between several files.

The first commits creates rustc_resolve::probe module to hold the different mutually recursive functions together. Just a move, no code change.
The following commits attempt to make the logic a bit more readable.

The two fields last_import_segment and unusable_binding are replaced by function parameters.
In order to manage the fallout, maybe_ variants of the function are added, dedicated to speculative resolution.

r? @petrochenkov

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 28, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 28, 2022
@petrochenkov
Copy link
Contributor

Some preliminary comments:

  • It's not clear why "probe" was chosen as the name
  • I'd prefer to move the fn report_error stuff to diagnostics.rs leaving other files primarily for "reference implementation of the language", if that makes sense
  • It's unfortunate that multiple versions of functions like fn maybe_foo + fn foo + fn foo_with_ribs + etc have to be introduced as a replacement for having optional function parameters at language level. The "maybe" naming doesn't even reflect that we are simply omitting some parameters with default values.
    I wish there was a better way to address this, but the alternative of creating a separate new FooArgs struct for every such function is even more awful.

petrochenkov
petrochenkov reviewed Mar 29, 2022
View reviewed changes
@petrochenkov petrochenkov 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 Mar 29, 2022
@petrochenkov petrochenkov 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. labels Apr 1, 2022
@cjgillot cjgillot 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 Apr 2, 2022
@cjgillot
Copy link
Contributor Author

cjgillot commented Apr 2, 2022

I believe this version addresses your first round of reviews. The refactor of resolve_path has been removed.

Some preliminary comments:

* It's not clear why "probe" was chosen as the name

Just because I found rustc_resolve::resolve silly. What would you prefer?

* I'd prefer to move the `fn report_error` stuff to diagnostics.rs leaving other files primarily for "reference implementation of the language", if that makes sense

Done.

* It's unfortunate that multiple versions of functions like `fn maybe_foo` + `fn foo` + `fn foo_with_ribs` + etc have to be introduced as a replacement for having optional function parameters at language level. The "maybe" naming doesn't even reflect that we are simply omitting some parameters with default values.
  I wish there was a better way to address this, but the alternative of creating a separate new `FooArgs` struct for every such function is even more awful.

I understand the maybe_ version to be suitable for speculative resolution. Is it correct with those parameters?

@rust-log-analyzer

This comment has been minimized.

# to view
@petrochenkov
Copy link
Contributor

Just because I found rustc_resolve::resolve silly. What would you prefer?

Well, if we have macros.rs for macro-specific stuff, and imports.rs for import-specific stuff, them maybe we should have ident(s).rs for identifier resolution stuff (which I see moved to this new file).

(resolve_path(_with_ribs) should ideally be a nearly trivial loop over resolving identifiers, so it doesn't deserve its own file or file naming.)

@bors

This comment was marked as resolved.

# to view
@cjgillot cjgillot 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. labels Apr 8, 2022
@petrochenkov petrochenkov 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 Apr 12, 2022
@cjgillot cjgillot 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. labels Apr 12, 2022
@petrochenkov
Copy link
Contributor

r=me with #95405 (comment) applied.

@petrochenkov petrochenkov 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 Apr 12, 2022
@cjgillot
Copy link
Contributor Author

@bors r=petrochenkov

@bors
Copy link
Collaborator

bors commented Apr 12, 2022

📌 Commit 276b946 has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 12, 2022
@Dylan-DPC Dylan-DPC mentioned this pull request Apr 12, 2022
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 13, 2022
@bors
Auto merge of rust-lang#95990 - Dylan-DPC:rollup-r9bh9t7, r=Dylan-DPC
1491e5c 
Rollup of 7 pull requests

Successful merges:

 - rust-lang#95316 (Rustdoc: Discriminate required and provided associated constants and types)
 - rust-lang#95405 (Move name resolution logic to a dedicated file)
 - rust-lang#95914 (Implement tuples using recursion)
 - rust-lang#95918 (Delay a bug when we see SelfCtor in ref pattern)
 - rust-lang#95970 (Fix suggestions in case of `T:` bounds)
 - rust-lang#95973 (prevent opaque types from appearing in impl headers)
 - rust-lang#95986 (Autolabel library PRs with T-libs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2743c13 into rust-lang:master Apr 13, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 13, 2022
@cjgillot cjgillot deleted the probe branch April 13, 2022 17:37
@petrochenkov petrochenkov mentioned this pull request Apr 30, 2022
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request May 1, 2022
@bors
Auto merge of rust-lang#96582 - petrochenkov:finalize, r=cjgillot
a933de8 
resolve: Cleanup path resolution finalization

Some cleanup after rust-lang#95255 and rust-lang#95405.
r? `@cjgillot`
# for free to join this conversation on GitHub. Already have an account? # to comment
Reviewers

@petrochenkov petrochenkov

Assignees

@petrochenkov petrochenkov

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.62.0
Development

Successfully merging this pull request may close these issues.
6 participants
@cjgillot @petrochenkov @rust-log-analyzer @bors @rust-highfive @rustbot