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 Spans from HIR #72015

Closed
wants to merge 41 commits into from
Closed

Remove Spans from HIR #72015

wants to merge 41 commits into from

Conversation

cjgillot
Copy link
Contributor

@cjgillot cjgillot commented May 8, 2020

This PR is an experiment in removing the Span information from the HIR tree.
I plan to submit a MCP if this PR is considered relevant.

The spans are stored in a side table, indexed by HirId, and constructed during lowering.
A dedicated query is created to retrieve those spans.

Subsequent commits gradually remove spans from HIR nodes.
Those are quite mechanical, and don't deserve close examination before the MCP is accepted.

The point of this PR is to limit HIR invalidation due to span info changing.
At this stage, there are still a lot of spans in the HIR.
I do not think we will see benefits while there are some.

Anyway, I would like to get a few comment wrt. the soundness of the approach.

@rust-highfive

This comment has been minimized.

@bors

This comment has been minimized.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 9, 2020
@cjgillot cjgillot marked this pull request as draft May 9, 2020 14:08
@cjgillot cjgillot changed the title WIP: Remove Spans from HIR Remove Spans from HIR May 9, 2020
@rust-highfive

This comment has been minimized.

@varkor
Copy link
Member

varkor commented May 9, 2020

Not sure who's most appropriate to review. Maybe r? @petrochenkov?

@rust-highfive rust-highfive assigned petrochenkov and unassigned varkor May 9, 2020
@bors

This comment has been minimized.

@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 May 9, 2020
@cjgillot
Copy link
Contributor Author

cc #47389.

@petrochenkov
Copy link
Contributor

Spans that are not in Idents should mostly be used for diagnostics in case of errors so it shouldn't be a performance issue it they are moved to a side table (there may be exceptions, I'm not sure).

If this allows to not hash spans in most cases and hash them only in rare cases in which they are really needed, then this should be an improvement.
I don't really understand how incremental works in detail, so I can't give any design advice besides that.

r? @nikomatsakis because you mentioned this recently in #51003 (comment)

@nikomatsakis
Copy link
Contributor

Interesting! So, to make sure I understand the approach:

  • Create a map (during lowering) from HirId -> Span during HIR lowering
  • Remove the spans from the HIR itself (or, presumably, most spans -- maybe some HIR nodes have multiple spans)
  • Create a query span_of(HirId) (say) that returns the span for a given HirId

I think an MCP would be most appropriate, yes. I also suspect that @pnkfelix is the right reviewer, as he's been interested in getting more involved in this area, but I'll let him volunteer if he feels he has time.

@bors
Copy link
Contributor

bors commented May 12, 2020

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

@pnkfelix pnkfelix self-assigned this May 12, 2020
@pnkfelix
Copy link
Member

@cjgillot Do we have metrics for how much (if any) invalidation this eliminates?

(As you said a lot of spans still remain, I wouldn't be surprised if the net change is approximately zero. But I am still curious whether we can easily gather data here.)

@cjgillot
Copy link
Contributor Author

I have no idea how to gather such data. A possibility would be a perf run, and look at the "println incremental" lines. Does perf handle comparing "clean incremental" and "println incremental"?

@Mark-Simulacrum
Copy link
Member

@bors try @rust-timer queue

Well, a perf run certainly can't hurt -- and since CI seems to be passing might as well try it out.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented May 12, 2020

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout nospan (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self nospan --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging src/librustdoc/test.rs
Auto-merging src/librustc_trait_selection/traits/error_reporting/suggestions.rs
Auto-merging src/librustc_passes/region.rs
Auto-merging src/librustc_passes/liveness.rs
Auto-merging src/librustc_mir_build/hair/pattern/check_match.rs
Auto-merging src/librustc_mir_build/build/mod.rs
Auto-merging src/librustc_mir_build/build/matches/mod.rs
Auto-merging src/librustc_mir_build/build/block.rs
Auto-merging src/librustc_middle/hir/mod.rs
CONFLICT (content): Merge conflict in src/librustc_middle/hir/mod.rs
Auto-merging src/librustc_ast_lowering/lib.rs
Automatic merge failed; fix conflicts and then commit the result.

@cjgillot
Copy link
Contributor Author

Rebased.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Mar 15, 2021

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

@jackh726
Copy link
Member

jackh726 commented May 3, 2021

@cjgillot Is this waiting for a review or do you plan to do more here?

@cjgillot
Copy link
Contributor Author

cjgillot commented May 4, 2021

@jackh726 I believe this PR is not the right solution for the issue of span invalidation.

@cjgillot cjgillot closed this May 4, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 31, 2021
Remove `rustc_hir::hir_id::HirIdVec`

See rust-lang#90408 (comment):

> IIRC, `HirIdVec` is never used, you can delete it. PR rust-lang#72015 has been abandoned.

r? `@cjgillot`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 1, 2021
Remove `rustc_hir::hir_id::HirIdVec`

See rust-lang#90408 (comment):

> IIRC, `HirIdVec` is never used, you can delete it. PR rust-lang#72015 has been abandoned.

r? `@cjgillot`
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. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.