Move the extended lifetime resolution into typeck context#95563
Move the extended lifetime resolution into typeck context#95563bors merged 1 commit intorust-lang:masterfrom
Conversation
|
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
8b98476 to
602c945
Compare
|
☔ The latest upstream changes (presumably #95656) made this pull request unmergeable. Please resolve the merge conflicts. |
602c945 to
30c8717
Compare
|
☔ The latest upstream changes (presumably #94468) made this pull request unmergeable. Please resolve the merge conflicts. |
30c8717 to
bee6bd1
Compare
nikomatsakis
left a comment
There was a problem hiding this comment.
Left some nits, but the bigger question is: can we move the "rvalue candidate" stuff into the same place that the scopes are computed? (typeck)
I think we will want that eventually, because the candidates will be influenced by the results of type check.
There was a problem hiding this comment.
| /// `rvalue_candidates` includes entries that are selected for extended | |
| /// lifetime according to rvalue scoping rules. | |
| /// Those candidates will be considered for extension of a lifetime, | |
| /// whose cleanup scope will be larger than the default. | |
| /// For rvalues not present in this table, | |
| /// the appropriate cleanup scope is the innermost enclosing statement, | |
| /// conditional expression, or repeating block (see `terminating_scopes`). | |
| /// Identifies expressions which, if captured into a temporary, ought to | |
| /// have a temporary whose lifetime extends to the end of the enclosing *block*, | |
| /// and not the enclosing *statement*. (See `RvalueCandidate` for more information.) |
There was a problem hiding this comment.
| bug!("rvalue scope information is not avilable yet") | |
| bug!("rvalue scope information is not available yet") |
maybe make this a span_bug? always better.
There was a problem hiding this comment.
| bug!("rvalue scope information is not available yet") | |
| bug!("rvalue scope information is not available yet") |
span bug!
There was a problem hiding this comment.
Why not move the definition into this file and pub use it from the super module, if necessary?
There was a problem hiding this comment.
This deserves a comment for sure =)
There was a problem hiding this comment.
| pub inner: FxHashMap<hir::ItemLocalId, Option<Scope>>, | |
| map: FxHashMap<hir::ItemLocalId, Option<Scope>>, |
Nit: I'd move the things that manipulate the map to methods on RvalueScopes (and move this definition over to where its impl is)
There was a problem hiding this comment.
Yes, I think making it pub was actually not necessary.
bee6bd1 to
6547d94
Compare
bea3352 to
3957b0a
Compare
|
☔ The latest upstream changes (presumably #96473) made this pull request unmergeable. Please resolve the merge conflicts. |
49783a5 to
3091472
Compare
|
☔ The latest upstream changes (presumably #97019) made this pull request unmergeable. Please resolve the merge conflicts. |
3091472 to
1460a75
Compare
|
☔ The latest upstream changes (presumably #97239) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
left a comment
There was a problem hiding this comment.
Yes, this looks great!
|
@bors delegate+ @dingxiangfei2009 This is r=me but I can't r+ because it needs a rebase. I'm delegating to you so that you can rebase and then do |
|
✌️ @dingxiangfei2009 can now approve this pull request |
3ef602d to
0cb3dfe
Compare
This comment has been minimized.
This comment has been minimized.
remove region_scope_tree from RegionCtxt Apply suggestions from code review Co-authored-by: Niko Matsakis <[email protected]>
0cb3dfe to
6044fbe
Compare
|
📌 Commit 6044fbe has been approved by |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (6534637): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
@nikomatsakis @dingxiangfei2009 It looks like this PR was a regression across a fairly large number of incremental benchmarks -- I don't see a previous perf run done on this PR or discussion of performance as part of this change. Was this regression expected at an architectural level? It looks like non-incremental benchmarks actually improved, so perhaps we're not caching something we were before? |
|
|
||
| /// Per-body `region::ScopeTree`. The `DefId` should be the owner `DefId` for the body; | ||
| /// in the case of closures, this will be redirected to the enclosing function. | ||
| query region_scope_tree(def_id: DefId) -> &'tcx region::ScopeTree { |
There was a problem hiding this comment.
@Mark-Simulacrum I think by removing region_scope_tree from the list of queries, I suspect that the caching is lost since this computation could get repeated.
|
I have a question now. Is there a way to cache things by keys of type I will make a PR to restore that query and see if the perf numbers are restored. |
|
In addition to the instruction count regression, it seems like it also caused a regression to the compiler's memory usage (max-rss): Will restoring the query also address the max-rss regression? |
…-tree-query, r=dingxiangfei2009 Try to cache region_scope_tree as a query This PR will attempt to restore `region_scope_tree` as a query so that caching works again. It seems that `region_scope_tree` could be re-computed for nested items after all, which could explain the performance regression introduced by rust-lang#95563. cc `@Mark-Simulacrum` `@pnkfelix` I will try to trigger a perf run here.
Related to #15023
This PR is based on the idea of #15023 by @nikomatsakis.
This PR specifically proposes to