user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

prevent incorrect layout error

Browse source 
aliases may be rigid even if they don't reference params. If the alias isn't well-formed, trying to normalize it as part of the input should have already failed

(cherry picked from commit 39a532445a)
This commit is contained in:
lcnr 2026-02-10 18:00:42 +00:00 • committed by Josh Stone
parent 4dbbfa3087
commit 25c0e0569c
1 changed files with 12 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

18
compiler/rustc_ty_utils/src/layout.rs
View file

@ -764,14 +764,20 @@ fn layout_of_uncached<'tcx>(
}
ty::Alias(..) => {
// NOTE(eddyb) `layout_of` query should've normalized these away,
// if that was possible, so there's no reason to try again here.
let err = if ty.has_param() {
// In case we're still in a generic context, aliases might be rigid. E.g.
// if we've got a `T: Trait` where-bound, `T::Assoc` cannot be normalized
// in the current context.
//
// For some builtin traits, generic aliases can be rigid even in an empty environment,
// e.g. `<T as Pointee>::Metadata`.
//
// Due to trivial bounds, this can even be the case if the alias does not reference
// any generic parameters, e.g. a `for<'a> u32: Trait<'a>` where-bound means that
// `<u32 as Trait<'static>>::Assoc` is rigid.
let err = if ty.has_param() || !cx.typing_env.param_env.caller_bounds().is_empty() {
LayoutError::TooGeneric(ty)
} else {
// This is only reachable with unsatisfiable predicates. For example, if we have
// `u8: Iterator`, then we can't compute the layout of `<u8 as Iterator>::Item`.
LayoutError::Unknown(ty)
unreachable!("invalid rigid alias in layout_of after normalization: {ty:?}");
};
return Err(error(cx, err));
}