Files
rust/tests/ui/issues
Matthias Krüger 67278cd9f4 Rollup merge of #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: https://github.com/rust-lang/rust/pull/133392#issuecomment-2508769703

Fixes #133388

[^crater]: I cratered this originally with #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.
2024-12-14 23:56:30 +01:00
..
2024-12-13 00:04:56 +00:00
2024-02-07 10:42:01 +08:00
2024-01-05 10:00:59 +00:00
2024-02-07 10:42:01 +08:00
2024-02-07 10:42:01 +08:00
2023-01-11 14:40:02 -08:00
2023-12-20 22:53:56 -05:00
2024-12-12 23:36:27 +00:00
2024-02-07 10:42:01 +08:00
2024-01-13 12:46:58 -05:00
2024-07-06 14:24:20 +02:00
2023-05-01 16:15:13 +08:00
2024-02-07 10:42:01 +08:00
2023-11-16 17:00:23 +00:00
2024-11-24 00:19:47 +00:00
2024-11-24 00:19:47 +00:00
2023-04-08 21:32:55 +00:00
2024-01-05 10:00:59 +00:00
2024-01-13 12:46:58 -05:00
2023-11-16 17:00:23 +00:00
2024-02-07 10:42:01 +08:00
2024-07-10 17:15:02 -04:00
2024-07-10 17:15:02 -04:00
2024-04-29 14:53:38 +02:00
2023-01-15 19:46:20 +00:00
2023-01-15 19:46:20 +00:00
2024-02-07 10:42:01 +08:00
2024-11-22 02:32:26 +00:00
2024-11-22 02:32:26 +00:00
2023-06-26 08:56:32 +00:00
2023-11-24 21:04:51 +01:00
2024-04-22 18:48:47 +02:00