-
Notifications
You must be signed in to change notification settings - Fork 0
our folding strategy in check_type_bound
is insufficient
#116
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
check_type_bound
sufficient?check_type_bound
is insufficient?
check_type_bound
is insufficient?check_type_bound
is insufficient
structurally folding instead of using ordinary normalization also avoids proving the trait assoc-type where-clauses when checking that the impl definition is wf, causing tests/ui/generic-associated-types/issue-91883.rs to pass: |
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
Feb 18, 2025
…tem-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 18, 2025
…tem-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Feb 18, 2025
…tem-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 18, 2025
…tem-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 18, 2025
…tem-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 19, 2025
Rollup merge of rust-lang#137000 - compiler-errors:deeply-normalize-item-bounds, r=lcnr Deeply normalize item bounds in new solver Built on rust-lang#136863. Fixes rust-lang/trait-system-refactor-initiative#142. Fixes rust-lang/trait-system-refactor-initiative#151. cc rust-lang/trait-system-refactor-initiative#116 First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env. Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out. r? lcnr
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Uh oh!
There was an error while loading. Please reload this page.
rust-lang/rust#125786 folds associated type bounds to replace associated types w/ their concrete types. However, it only does it for identity-substituted associated types, and only for the associated type that we're checking.
This is known to be insufficient, see rust-lang/rust#135246. Fixing this likely relies on proving item-bounds during normalization and also affects the old solver. We will probably only fix this issue after stabilization.
edit: old description
This seems to be sufficient, but I'm somewhat suspicious about things like:
We should revisit this strategy and convince ourselves it's sound before stabilization, or else make it more general (which doesn't seem too difficult).
Previous unsoundnesses:
associated_type_defaults
are unsound in the new solver #46The text was updated successfully, but these errors were encountered: