-
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
split NormalizesTo
out of Projection
3
#118725
Conversation
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.
5c0809e
to
ffb4c08
Compare
@@ -1,5 +1,7 @@ | |||
// compile-flags: -Ztrait-solver=next | |||
// known-bug: trait-system-refactor-initiative#60 | |||
// dont-check-failure-status | |||
// dont-check-compiler-stderr |
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 test now ICEs, but given that it's already buggy I don't want this to block merging this PR. Will look at it separately.
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.
would be fixed by actually reporting errors in writeback if normalization fails. Unfortunately that ICEs because regions have already been resolved. Will do this in a separate PR, temp diff 193abb3
match a_ty.kind() { | ||
&ty::Alias(ty::AliasKind::Projection, data) => { | ||
// FIXME: This does not handle subtyping correctly, we should switch to | ||
// alias-relate in the new solver and could instead create a new inference |
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.
we do use alias relate in the new solver like 2 lines above. is this still relevant?
r? @BoxyUwU |
@bors r+ rollup=never p=1 (i dont trust adding new predicate kinds to not be conflicty and also i mgiht be perf) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (21982a4): comparison URL. Overall result: ❌✅ regressions and improvements - 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.561s -> 673.716s (-0.27%) |
probably caused by adding the new |
perf: experiment with only non-functional changes from rust-lang#118725 cc rust-lang#118735 r? `@ghost`
callgrind diff of bors builds:
The regressed crates are exactly the ones that benefit the most from #117749 where predicate interning and folding is very hot. I don't think there is much that can be done to mitigate the impact. Each function runtime has increased by few instructions as expected but that's enough to make a difference because of how much hot they are. |
refactor infer var storage cleanup the code, discovered while working on rust-lang#118725
refactor writeback: emit normalization errors with new solver implements rust-lang#118725 (comment) r? `@compiler-errors` `@BoxyUwU` whoever comes first n stuff
…rrors refactor infer var storage cleanup the code, discovered while working on rust-lang#118725
…rors refactor writeback: emit normalization errors with new solver implements rust-lang#118725 (comment) r? `@compiler-errors` `@BoxyUwU` whoever comes first n stuff
…, r=lcnr Unconditionally register alias-relate in projection goal Follow-up to rust-lang#118725, which subtly broke closure signature inference on combinators like `Result::map` which I noticed in syn. Essentially, instead of using `eq` which will eagerly infer `?1 := <?2 as Trait>::Assoc`, we can directly emit an alias-relate goal, which will stay ambiguous for as long as `?2` is ambiguous. This also more closely models the conceptual framing that projects-to acts like an alias-relate when solving, and like a normalizes-to when in a param env. r? lcnr
…, r=lcnr Unconditionally register alias-relate in projection goal Follow-up to rust-lang#118725, which subtly broke closure signature inference on combinators like `Result::map` which I noticed in syn. Essentially, instead of using `eq` which will eagerly infer `?1 := <?2 as Trait>::Assoc`, we can directly emit an alias-relate goal, which will stay ambiguous for as long as `?2` is ambiguous. This also more closely models the conceptual framing that projects-to acts like an alias-relate when solving, and like a normalizes-to when in a param env. r? lcnr
Rollup merge of rust-lang#118914 - compiler-errors:eager-alias-relate, r=lcnr Unconditionally register alias-relate in projection goal Follow-up to rust-lang#118725, which subtly broke closure signature inference on combinators like `Result::map` which I noticed in syn. Essentially, instead of using `eq` which will eagerly infer `?1 := <?2 as Trait>::Assoc`, we can directly emit an alias-relate goal, which will stay ambiguous for as long as `?2` is ambiguous. This also more closely models the conceptual framing that projects-to acts like an alias-relate when solving, and like a normalizes-to when in a param env. r? lcnr
third attempt at #112658. Rebasing #116262 is very annoying, so I am doing it again from scratch. We should now be able to merge it without regressing anything as we handle occurs check failures involving aliases correctly since #117088.
see https://hackmd.io/ktEL8knTSYmtdfrMMnA-Hg
fixes rust-lang/trait-system-refactor-initiative#1
r? @compiler-errors