-
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
Add all RPITITs when augmenting param-env with GAT bounds in check_type_bounds
#117131
Conversation
3d251d8
to
d40fd3d
Compare
This comment has been minimized.
This comment has been minimized.
ca6f45c
to
bfd836b
Compare
Is there a (relatively) easy way to build a compiler from this PR before it gets merged? This bug is blocking me. |
@bors r+ rollup |
@bors rollup=never |
Add all RPITITs when augmenting param-env with GAT bounds in `check_type_bounds` When checking that associated type definitions actually satisfy their associated type bounds in `check_type_bounds`, we construct a "`normalize_param_env`" which adds a projection predicate that allows us to assume that we can project the GAT to the definition we're checking. For example, in: ```rust type Foo { type Bar: Display = i32; } ``` We would add `<Self as Foo>::Bar = i32` as a projection predicate when checking that `i32: Display` holds. That `normalize_param_env` was, for some reason, only being used to normalize the predicate before it was registered. This is sketchy, because a nested obligation may require the GAT bound to hold, and also the projection cache is broken and doesn't differentiate projection cache keys that differ by param-envs 😿. This `normalize_param_env` is also not sufficient when we have nested RPITITs and default trait methods, since we need to be able to assume we can normalize both the RPITIT and all of its child RPITITs to sufficiently prove all of its bounds. This is the cause of rust-lang#117104, which only starts to fail for RPITITs that are nested 3 and above due to the projection-cache bug above.[^1] ## First fix Use the `normalize_param_env` everywhere in `check_type_bounds`. This is reflected in a test I've constructed that fixes a GAT-only failure. ## Second fix For RPITITs, install projection predicates for each RPITIT in the same function in `check_type_bounds`. This fixes rust-lang#117104. not sure who to request, so... r? `@lcnr` hehe feel free to reassign :3 [^1]: The projection cache bug specifically occurs because we try normalizing the `assumed_wf_types` with the non-normalization param-env. This causes us to insert a projection cache entry that keeps the outermost RPITIT rigid, and it trivially satisifes all its own bounds. Super sketchy![^2] [^2]: I haven't actually gone and fixed the projection cache bug because it's only marginally related, but I could, and it should no longer be triggered here.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
bfd836b
to
b0ee801
Compare
b0ee801
to
dd571e4
Compare
@bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2520ca8): 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: 635.107s -> 636.745s (0.26%) |
82: Automated pull from upstream `master` r=tshepang a=github-actions[bot] This PR pulls the following changes from the upstream repository: * rust-lang/rust#117313 * rust-lang/rust#117131 * rust-lang/rust#117134 * rust-lang/rust#117471 * rust-lang/rust#117521 * rust-lang/rust#117513 * rust-lang/rust#117512 * rust-lang/rust#117509 * rust-lang/rust#117495 * rust-lang/rust#117394 * rust-lang/rust#117466 * rust-lang/rust#117204 * rust-lang/rust#117386 * rust-lang/rust#117506 Co-authored-by: Nicholas Nethercote <n.nethercote@gmail.com> Co-authored-by: roblabla <unfiltered@roblab.la> Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: massivebird <gdrakemail@gmail.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Zalathar <Zalathar@users.noreply.github.com> Co-authored-by: lcnr <rust@lcnr.de> Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com> Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
alright... that's bad 😅 how tf does |
Only instantiate binder during dyn's built-in trait candidate probe once See UI test for demonstration of the issue. This was "caused" by rust-lang#117131, but only because we're using the `normalize_param_env` (which has been augmented with a projection clause used to normalize GATs) which features non-lifetime bound vars in it. Fixes rust-lang#117602 technically, though that's also fixed by rust-lang#117542. r? types
@rustbot label: +perf-regression-triaged |
When checking that associated type definitions actually satisfy their associated type bounds in
check_type_bounds
, we construct a "normalize_param_env
" which adds a projection predicate that allows us to assume that we can project the GAT to the definition we're checking. For example, in:We would add
<Self as Foo>::Bar = i32
as a projection predicate when checking thati32: Display
holds.That
normalize_param_env
was, for some reason, only being used to normalize the predicate before it was registered. This is sketchy, because a nested obligation may require the GAT bound to hold, and also the projection cache is broken and doesn't differentiate projection cache keys that differ by param-envs 😿.This
normalize_param_env
is also not sufficient when we have nested RPITITs and default trait methods, since we need to be able to assume we can normalize both the RPITIT and all of its child RPITITs to sufficiently prove all of its bounds. This is the cause of #117104, which only starts to fail for RPITITs that are nested 3 and above due to the projection-cache bug above.1First fix
Use the
normalize_param_env
everywhere incheck_type_bounds
. This is reflected in a test I've constructed that fixes a GAT-only failure.Second fix
For RPITITs, install projection predicates for each RPITIT in the same function in
check_type_bounds
. This fixes #117104.not sure who to request, so...
r? @lcnr hehe feel free to reassign :3
Footnotes
The projection cache bug specifically occurs because we try normalizing the
assumed_wf_types
with the non-normalization param-env. This causes us to insert a projection cache entry that keeps the outermost RPITIT rigid, and it trivially satisifes all its own bounds. Super sketchy!2 ↩I haven't actually gone and fixed the projection cache bug because it's only marginally related, but I could, and it should no longer be triggered here. ↩