Well-formedness (e.g. `where` bound from struct) unenforced in associated types

[steffahn]

While trying out variants of the code in #154172, I came up with this example

trait Bound {}
struct Bounded<B: Bound>(B);

trait Tr {
    type TrAssoc;
}
impl<T> Tr for T {
    type TrAssoc = i32;
}

trait Simple {
    type SimpleAssoc;
}

impl Simple for () {
    type SimpleAssoc = <Bounded<()> as Tr>::TrAssoc; // okay?
}

fn main() {
    // let n: <Bounded<()> as Tr>::TrAssoc = 123; // error
    let n: <() as Simple>::SimpleAssoc = 123; // okay?
}

It seems inconsistent that <Bounded<()> as Tr>::TrAssoc is disallowed in main, but not an issue if used in type SimpleAssoc = … (even when that associated type is later used in main).

I have – thus far – no reason to suspect this is causing unsoundness; but it seems unfortunate that () can be passed to Bounded without fulfilling (): Bound even when the concrete type, then, is largely irrelevant for it’s unused in the blanket impl of trait Tr, and the whole thing normalizes to i32

Interestingly, the first line in main too used to compile before Rust 1.68. I bisected that change more precisely to this range

get_commits_between returning commits, len: 7
  commit[0] 2023-01-08: Auto merge of #106449 - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum
  commit[1] 2023-01-08: Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnay
  commit[2] 2023-01-09: Auto merge of #106616 - compiler-errors:rollup-emcj0o3, r=compiler-errors
  commit[3] 2023-01-09: Auto merge of #106582 - compiler-errors:better-spans-on-bad-tys, r=lcnr
  commit[4] 2023-01-09: Auto merge of #106340 - saethlin:propagate-operands, r=oli-obk
  commit[5] 2023-01-09: Auto merge of #101947 - aliemjay:astconv-normalize, r=lcnr
  commit[6] 2023-01-09: Auto merge of #106637 - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead

and I'm suspecting the PR for that improvement (rejecting more problematic code) might have been #101947

[fmease]

Dupe of #100041.

[fmease]

It's unenforced in various places, namely in most if not all item ctxts = item signatures = non-bodies.

I've removed fixed-by-next-solver from the linked issue again (which I added at some point) because it doesn't actually fix all instances of it.

You can minimize it to e.g.:

trait Discard { type Output; }
impl<T> Discard for T { type Output = (); }

struct Hold(<Vec<str> as Discard>::Output);

[steffahn]

Dupe of #100041.

Ah, I had eyed #⁠100041 but not re-evaluated it for duplicates more closely as after noticing the I-unsound label it has. (Looking at it now, I'm not completely sure I understand why it has that label though!)

I'm happy to close this issue as a duplicate if that seems correct to you :-)