-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement deferred_projection_equality
for erica solver
#107507
Conversation
r? @jackh726 (rustbot has picked a reviewer for you, use r? to override) |
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
Outdated
Show resolved
Hide resolved
bbed750
to
d999f00
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
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.
only looked at solver impl, but alright looks pretty nice.
bd77e37
to
6393303
Compare
☔ The latest upstream changes (presumably #107434) made this pull request unmergeable. Please resolve the merge conflicts. |
6393303
to
a38e363
Compare
// Ignore bounds that a user can't type | ||
WellFormed(..) | | ||
ObjectSafe(..) | | ||
ClosureKind(..) | | ||
Subtype(..) | | ||
Coerce(..) | | ||
// FIXME(generic_const_exprs): `ConstEvaluatable` can be written |
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.
same for WellFormed
, isn't it 😁
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.
yea
@@ -310,10 +310,12 @@ pub(crate) fn clean_predicate<'tcx>( | |||
ty::PredicateKind::Clause(ty::Clause::Projection(pred)) => { | |||
Some(clean_projection_predicate(bound_predicate.rebind(pred), cx)) | |||
} | |||
// FIXME(generic_const_exprs): should this do something? |
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.
nope, unreachable anyways (hopefully)
☔ The latest upstream changes (presumably #101680) made this pull request unmergeable. Please resolve the merge conflicts. |
a38e363
to
deaea6a
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.
very cool :3
r=me after final nits (and perf i guess)
tests/ui/traits/new-solver/alias_eq_dont_use_normalizes_to_if_substs_eq.rs
Show resolved
Hide resolved
tests/ui/traits/new-solver/normalizes_to_ignores_unnormalizable_candidate.rs
Outdated
Show resolved
Hide resolved
tests/ui/traits/new-solver/normalizes_to_ignores_unnormalizable_candidate.rs
Outdated
Show resolved
Hide resolved
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit deaea6a7570b74033e739a622862c3cb720289fc with merge 9ea0bea458fc11f79a038ebaab04bd654183277f... |
⌛ Trying commit 4c98429 with merge ae79965995e38045893ccc99907b3efabd9475f2... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (ae79965995e38045893ccc99907b3efabd9475f2): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
@bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1623ab0): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
noise |
Doing perf triage - @BoxyUwU are you sure this is noise? Looking at the graphs, it looks like this change was sustained. The graph shoes changes from the previous run and the spike is this change. Noise is usually indicated by a corresponding correction in the other direction which this doesn't have. The change is large enough that it might be worth looking into. Given that the regression is in Diesel which exercises the type checker really heavily it's not so surprising that we might find a regression there. |
we did a perf run before landing this and it was fine and nothing had changed since. |
@BoxyUwU unfortunately there can still be a perf regression. It's possible that changes introduced in master since you first ran the perf regression interact with these change differently causing these changes to introduce perf regressions. In other words, it's completely possible for a perf run to show no regressions and then regressions to appear after the change is merged into master. That's not noise unfortunately. A change of 1% against a popular crate isn't huge but it's also not small. Then again the significance factors are fairly low. It's only .5 times higher than the significance threshold. I'll leave it up to you and @lcnr to decide (please do leave your decision with the label "perf-regression-triaged" set). |
This PR doesn't really do Much stable facing, it looks a lot bigger than it actually is. The only changes that could really effect anything would be
I don't think we can really do anything about second thing, the first thing otoh will go away when the new solver is stabilized and the old one is removed. Lazy norm afaik is pretty much required long term for rustc, there are soundness bugs caused by us not having it, and its generally a bit of a nightmare attempting to maintain and implement stuff in the type system without. Probably just have to eat this regression? |
I bet the new |
I'm just going to weigh in a little bit here: First, it's not completely clear that this regression is or isn't noise; I've seen both regressions and improvements to diesel and the like of this magnitude that are nearly certainly noise. If this is noise, just because we haven't seen the correction "yet" doesn't mean we won't at some point in the future. Second, to expand on that a bit, while it is true that one perf run to the next can mean that the base has changed enough to cause a regression, the time between these in this case was less than 12 hours. In the time between perf builds, there were two commits, one clippy update and one mir opt (#85158); neither touched trait code, but it could very well be that the mir opt could cause a difference with this PR. However, I'm not really even confident in saying that. Third, to be frank, the regression here (noise or not) is certainly acceptable. The work in this PR is critical for future trait solver endeavors. Because the regression is basically in the "noise" range, I don't think it's something we should even think about if there is something to "unregress" perf. |
That's certainly a valid path forward. Given the additional context here, it seems like it's likely the right one too.
This is just the context I was looking for. Since the perf triagers are not involved in the day to day of many of the compiler changes we see, we rely on the authors and reviewers to give us this additional context to know whether the regression is worth poking into more. |
…, r=lcnr Implement `deferred_projection_equality` for erica solver Somewhat of a revival of rust-lang#96912. When relating projections now emit an `AliasEq` obligation instead of attempting to determine equality of projections that may not be as normalized as possible (i.e. because of lazy norm, or just containing inference variables that prevent us from resolving an impl). Only do this when the new solver is enabled
Somewhat of a revival of #96912. When relating projections now emit an
AliasEq
obligation instead of attempting to determine equality of projections that may not be as normalized as possible (i.e. because of lazy norm, or just containing inference variables that prevent us from resolving an impl). Only do this when the new solver is enabled