prevent incorrect layout error

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

compiler/rustc_ty_utils/src/layout.rs

@@ -764,14 +764,20 @@ fn layout_of_uncached<'tcx>(
         }
 
         ty::Alias(..) => {
-            // NOTE(eddyb) `layout_of` query should've normalized these away,
+            // In case we're still in a generic context, aliases might be rigid. E.g.
-            // if that was possible, so there's no reason to try again here.
+            // if we've got a `T: Trait` where-bound, `T::Assoc` cannot be normalized
-            let err = if ty.has_param() {
+            // 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
+                unreachable!("invalid rigid alias in layout_of after normalization: {ty:?}");
-                // `u8: Iterator`, then we can't compute the layout of `<u8 as Iterator>::Item`.
-                LayoutError::Unknown(ty)
             };
             return Err(error(cx, err));
         }