-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Move the extended lifetime resolution into typeck context #95563
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
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.
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.
/// `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`). |
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.
/// `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.) |
@@ -189,10 +190,15 @@ pub fn resolve_interior<'a, 'tcx>( | |||
kind: hir::GeneratorKind, | |||
) { | |||
let body = fcx.tcx.hir().body(body_id); | |||
let typeck_results = fcx.inh.typeck_results.borrow(); | |||
let Some(rvalue_scopes) = &typeck_results.rvalue_scopes else { | |||
bug!("rvalue scope information is not avilable yet") |
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.
bug!("rvalue scope information is not avilable yet") | |
bug!("rvalue scope information is not available yet") |
maybe make this a span_bug
? always better.
@@ -64,12 +65,16 @@ struct Cx<'tcx> { | |||
impl<'tcx> Cx<'tcx> { | |||
fn new(tcx: TyCtxt<'tcx>, def: ty::WithOptConstParam<LocalDefId>) -> Cx<'tcx> { | |||
let typeck_results = tcx.typeck_opt_const_arg(def); | |||
let Some(rvalue_scopes) = &typeck_results.rvalue_scopes else { | |||
bug!("rvalue scope information is not available yet") |
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.
bug!("rvalue scope information is not available yet") | |
bug!("rvalue scope information is not available yet") |
span bug!
use crate::middle::region::{Scope, ScopeData, ScopeTree}; | ||
use rustc_hir as hir; | ||
|
||
use super::context::RvalueScopes; |
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.
Why not move the definition into this file and pub use
it from the super
module, if necessary?
@@ -367,6 +368,11 @@ pub struct GeneratorInteriorTypeCause<'tcx> { | |||
pub expr: Option<hir::HirId>, | |||
} | |||
|
|||
#[derive(TyEncodable, TyDecodable, Clone, Debug, Eq, PartialEq, HashStable)] |
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.
This deserves a comment for sure =)
@@ -367,6 +368,11 @@ pub struct GeneratorInteriorTypeCause<'tcx> { | |||
pub expr: Option<hir::HirId>, | |||
} | |||
|
|||
#[derive(TyEncodable, TyDecodable, Clone, Debug, Eq, PartialEq, HashStable)] | |||
pub struct RvalueScopes { | |||
pub inner: FxHashMap<hir::ItemLocalId, Option<Scope>>, |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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.
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
💔 Test failed - checks-actions |
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? |
@@ -1048,12 +1048,6 @@ rustc_queries! { | |||
desc { "reachability" } | |||
} | |||
|
|||
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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