Repository navigation
Well-formedness (e.g. where bound from struct) unenforced in associated types #154194
Description
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
Activity
fmease commentedon Mar 22, 2026
Dupe of #100041.
fmease commentedon Mar 22, 2026
It's unenforced in various places, namely in most if not all item ctxts = item signatures = non-bodies.
I've removed
fixed-by-next-solverfrom 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.:
steffahn commentedon Mar 22, 2026
Ah, I had eyed #100041 but not re-evaluated it for duplicates more closely as after noticing the
I-unsoundlabel 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 :-)