Ensure type is monomorphic enough before evaluating size_of / align_of.

[tmiasko]

Helps with #149081.

r? oli-obk

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[davidhewitt]

Thanks, I also just arrived to pretty much the same diff and was about to push it 😂

I confirmed that the case in #149081 being related to debug assertions is because the pointer deference was triggering an alignment check (and causing evaluation of align_of).

[scottmcm]

Oh, fun, that failure is in this doctest:

        /// Whether the `Self` type is disallowed from mentioning generics (i.e. when used in an
        /// anonymous constant).
        ///
        /// HACK(min_const_generics): self types also have an optional requirement to **not**
        /// mention any generic parameters to allow the following with `min_const_generics`:
        /// ```
        /// # struct Foo;
        /// impl Foo { fn test() -> [u8; size_of::<Self>()] { todo!() } }
        ///
        /// struct Bar([u8; baz::<Self>()]);
        /// const fn baz<T>() -> usize { 10 }
        /// ```
        /// We do however allow `Self` in repeat expression even if it is generic to not break code
        /// which already works on stable while causing the `const_evaluatable_unchecked` future
        /// compat lint:
        /// ```
        /// fn foo<T>() {
        ///     let _bar = [1_u8; size_of::<*mut T>()];
        /// }
        /// ```
        // FIXME(generic_const_exprs): Remove this bodge once that feature is stable.
        forbid_generic: bool,

I was going to say the code here made sense to me, since it's what I think oli had suggested, but it seems the rabbit hole just keeps getting deeper...

[tmiasko]

I also included UI test changes for overview purposes, but this doesn't look like something we would like to land.

[oli-obk]

Ah the future incompatibility lint 😕

I guess we need a weaker check for now. Maybe we can just reject alias types for now?

Or maybe we make the layout logic itself return TooGeneric instead of failing with an error?

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

error: constant expression depends on a generic parameter
   --> compiler/rustc_hir/src/def.rs:583:23
    |
583 |     let _bar = [1_u8; size_of::<*mut T>()];
    |                       ^^^^^^^^^^^^^^^^^^^
    |
    = note: this may fail depending on what value the parameter takes

error: aborting due to 1 previous error; 1 warning emitted