obligations_for_self_ty: skip irrelevant goals (recompute sub_root from stalled_vars)#156187
Conversation
|
changes to cc @lcnr Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
This comment has been minimized.
This comment has been minimized.
90c0853 to
596f7e9
Compare
| .filter(|(_, stalled_on)| { | ||
| let Some(stalled_on) = stalled_on else { return true }; | ||
| stalled_on.stalled_vars.iter().filter_map(|arg| arg.as_type()).any(|ty| { | ||
| matches!(*ty.kind(), ty::Infer(ty::TyVar(tv)) if infcx.sub_unification_table_root_var(tv) == vid) |
There was a problem hiding this comment.
please shallow_resolve the stalled_var here and if it is not an inference variable, always return true for now.
There was a problem hiding this comment.
also, please add a comment explaining that we are conservative here and want to handle cases where a goal is no longer stalled
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…=<try> obligations_for_self_ty: skip irrelevant goals (recompute sub_root from stalled_vars)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
r? BoxyUwU given that it's largely my PR, let's give it to somebody else to review |
|
Finished benchmarking commit (1a8e5b7): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.4%, secondary -67.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -25.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 495.518s -> 495.667s (0.03%) |
| fn pending_obligations(&self) -> PredicateObligations<'tcx>; | ||
|
|
||
| /// Returning all pending obligations which reference an inference | ||
| /// variable with `_sub_root`. |
There was a problem hiding this comment.
should explicitly state that this can be conservative and return obligations which don't reference sub root
There was a problem hiding this comment.
Sorry for late update! Fixed, thank you!!
| // Conservative here: if any of its stalled vars are not infer var anymore, | ||
| // some unification happened, so this goal is no longer stalled. | ||
| // So include it to re-evaluate in the downstream. | ||
| stalled_on.stalled_vars.iter().filter_map(|arg| arg.as_type()).any( |
There was a problem hiding this comment.
can you add a comment about how we don't just use the sub roots from stalled_on as they may be out of date
There was a problem hiding this comment.
Fixed! sorry for my bad english T.T
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
38cdf1c to
6287f19
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot ready |
|
@bors r=BoxyUwU,lcnr |
|
Scheduling this before the next rollup, since there's few rollupable prs |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 057ed8b (parent) -> beae781 (this PR) Test differencesShow 1 test diffStage 2
Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard beae781308e9ddef13074a03faf57ca2fac59a5b --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (beae781): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -53.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -48.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 517.542s -> 523.273s (1.11%) |
View all comments
Supersedes #146759. Since the original PR is having conflict now, I've rebased.
This includes 2 commit
Why:
cached sub_roots can be stale if there is a sub-unification merge after stalling (lcnr proposed on the original PR)
so re-evaluating when reads ---> so more conservative
Testing:
-Zdisable-fast-pathsin trait solving #156172 with -Zdisable-fast-pathsStyle question:
In my preference, inside filter, I used filter_map - matches, but do you prefer if-let chain?
Original author: lcnr #146759
r? @lcnr