Recursive const stability checks do not apply in const items

[RalfJung]

All stable const fn in core/alloc/std are checked to ensure that they, transitively, do not use any unstable const features.

However, the same is not the case for const items. A stable fn can use array lengths, and a stable trait can have associated const, that use arbitrary unstable const features. That seems bad? I'm not entirely sure how to fix that though -- these items don't themselves have any stability, after all. They are just use in a large function (that may not even be a const fn).

One example where we are actually doing this is here:

rust/library/std/src/sys/pal/unix/process/process_unix.rs

Line 813 in 7f74c89

buf: [u8; unsafe { CMSG_SPACE(SCM_MSG_LEN as u32) as usize }],

CMSG_SPACE is a const fn defined in libc. It is not subject to any recursive const stability checks.

Cc @rust-lang/wg-const-eval @compiler-errors

[compiler-errors]

Thoughts:

• Anonymous constants and const {} blocks should probably inherit the const stability of their parent items, along w/ const checks should be enforced at the same level as their parent. We would then lint on the usage of CMSG_SPACE edit: unfinished thought

• As for associated constants, I actually have no idea... We probably should be required to put a const stability on const items in traits, and check them just like we do call terminators in the MIR const check. It shouldn't be too hard to validate Operand::Constant.

• However, I'm not totally sure how we should deal with const stability in impls vs traits. This is also likely very relevant to the way const stability will eventually work on traits vs impls in const traits...

[compiler-errors]

Also, IDK about the usage of unstable const operations in consts inside of non-const items 🤔