Repository navigation
Where-clauses on associated types are not checked for well-formedness #165177
Description
I tried this code:
pub struct NC<T: Copy>(pub T);
pub trait Tr {
type A where NC<String>: Sized;
}Expected: E0277 (String: Copy is not satisfied, required by NC). The same clause on a method in the same trait gives exactly that
error[E0277]: the trait bound `String: Copy` is not satisfied
4 | fn a() where NC<String>: Sized;
| ^^^^^ the trait `Copy` is not implemented for `String`
Actual: compiles, under both solvers, on nightly-2026-10-29 and on stable 1.99.0.
Meta
rustc --version --verbose:
rustc 1.101.0-nightly (92ffebece 2026-10-28)
binary: rustc
commit-hash: 92ffebeceaa0a071066f233873c2438e73d70fe7
commit-date: 2026-10-28
host: x86_64-unknown-linux-gnu
release: 1.101.0-nightly
LLVM version: 23.1.4
Stable comparison: rustc 1.99.0 (b940084d7 2026-09-28).
Activity
ManasDasri commentedon Oct 30, 2026
@rustbot claim
fmease commentedon Oct 30, 2026
fmease commentedon Oct 30, 2026
theemathas commentedon Oct 30, 2026
fmease commentedon Oct 30, 2026
fmease commentedon Oct 30, 2026
Not the case for assoc fns but it's also the case for assoc consts (under GCI).
Contrary to assoc tys & assoc consts, for assoc fns we do call
check_where_clausesincheck_fn_or_methodincheck_associated_item. That's the oversight.I wonder if the assoc ty case is a regression 🤔 a lot of refactorings happened in that area in the last two years moving things from HIR to middle::ty checks...doesn't look like it. Well, I've only checked 1.65 which is the version that stably intro'ed GATs.fmease commentedon Oct 30, 2026
@ManasDasri, ah, sorry I forgot that you used to be assigned. Ping me in your future PR so I can perf it & issue a crater run :)
Rollup merge of rust-lang#165184 - fmease:gci-wf-assoc-const-wc, r=kh…
Rollup merge of rust-lang#165184 - fmease:gci-wf-assoc-const-wc, r=kh…
Unrolled build for #165184 in rollup 165243