forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of rust-lang#133392 - compiler-errors:object-sup, r=lcnr Fix ICE when multiple supertrait substitutions need assoc but only one is provided Dyn traits must have all of their associated types constrained either by: 1. writing them in the dyn trait itself as an associated type bound, like `dyn Iterator<Item = u32>`, 2. A supertrait bound, like `trait ConstrainedIterator: Iterator<Item = u32> {}`, then you may write `dyn ConstrainedIterator` which doesn't need to mention `Item`. However, the object type lowering code did not consider the fact that there may be multiple supertraits with different substitutions, so it just used the associated type's *def id* as a key for keeping track of which associated types are missing: https://github.com/rust-lang/rust/blob/1fc691e6ddc24506b5234d586a5c084eb767f1ad/compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_compatibility.rs#L131 This means that we can have missing associated types when there are mutliple supertraits with different substitutions and only one of them is constrained, like: ```rust trait Sup<T> { type Assoc: Default; } impl<T: Default> Sup<T> for () { type Assoc = T; } impl<T: Default, U: Default> Dyn<T, U> for () {} trait Dyn<A, B>: Sup<A, Assoc = A> + Sup<B> {} ``` The above example allows you to name `<dyn Dyn<i32, u32> as Sup<u32>>::Assoc` even though it is not possible to project since it's neither constrained by a manually written projection bound or a supertrait bound. This successfully type-checks, but leads to a codegen ICE since we are not able to project the associated type. This PR fixes the validation for checking that a dyn trait mentions all of its associated type bounds. This is theoretically a breaking change, since you could technically use that `dyn Dyn<A, B>` type mentionedin the example above without actually *projecting* to the bad associated type, but I don't expect it to ever be relevant to a user since it's almost certainly a bug. This is corroborated with the crater results[^crater], which show no failures[^unknown]. Crater: rust-lang#133392 (comment) Fixes rust-lang#133388 [^crater]: I cratered this originally with rust-lang#133397, which is a PR that is stacked on top, then re-ran crater with just the failures from that PR. [^unknown]: If you look at the crater results, it shows all of the passes as "unknown". I believe this is a crater bug, since looking at the results manually shows them as passes.
- Loading branch information
Showing
10 changed files
with
184 additions
and
163 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.