Forbid `#[rustc_const_stable]` without `#[stable]`

[CraftSpider]

Currently, it is possible for a function in std to be marked stably const without the function being stable. In #79548, it was noted that rustdoc assumes that stably const implies stable, and that seems to be a reasonable requirement. There should be an error added to ensure the consistency of const stability.

[RalfJung]

Cc @rust-lang/wg-const-eval

[inquisitivecrystal]

Note that the Guide to Rustc Development says that #[rustc_const_stable] is permitted without #[stable].

[oli-obk]

This is needed for intrinsics, which are never stable (except for transmute). It may also be needed to allow an unstable const function to be used within a stable const function.

So these two attributes are actually independent. Const stability requirements are recursive in the body, unlike regular stability

[jhpratt]

Aside from intrinsics, are there any situations where this would be the desired behavior? I would imagine it's possible to special-case intrinsics.

[oli-obk]

I don't know, there may already be such use cases in libstd. If not, let's do this and worry about it when we have such a case

[jhpratt]

I'll give it a shot when I get a chance — probably next week at the earliest. My initial thought is to have a deny-by-default internal lint that is allowed for the intrinsics module.

[jhpratt]

As I just mentioned in #90356, I recommend this issue be closed. While intrinsics seems to be the most common use-case, others certainly exist. There is one existing usage in stdarch on a private method, and my attempt to fix a bug in const panic will likely introduce another usage.

[RalfJung]

Fine for me as long as we have a test which ensures that such a const fn cannot be directly called from stable user code in any way.

However, there seems to be another problematic case:

Much more problematic to me are stable const fns that have no rustc_const_* attribute at all, as that seems like an oversight and may be an accidental constness stabilization

Do we have an issue tracking that, or tests ensuring that this will work as expected (namely, such functions are not called in const-contexts in stable code)?