`rustc_const_unstable` on private items is confusing

[clarfonthey]

Problem

Right now, private items that use const-unstable things need one of the following:

1. rustc_const_unstable, to mark them as part of an unstable feature
2. rustc_const_stable_indirect, to mark these uses of const-unstable features as okay to be used indirectly in const-stable functions

This can be particularly confusing when trying to assign features to these functions, since in particular, either of these attributes is okay to add to any private item, regardless of whether they actually need it.

The main issue is that we want to track what const features are indirectly exposed to stable, but that we don't want to recursively inspect function bodies to do this.

Proposal

So, I propose a new solution: rustc_forward_const_fn_unstable.

This is similar to rustc_allow_const_fn_unstable, but specifically for private items, and it has slightly different semantics:

1. The features mentioned in the attribute must exist, be unstable, and be used in the body of the function.
2. After being processed, the function is treated as unstable with all the different features listed. (and the correct issues)

This effectively punts a rustc_allow_const_fn_unstable attribute down the line to a caller function if needed, helps avoid the issue where people just add the same const unstable feature to all methods they need it on, and avoids unnecessarily adding unstable features to const methods that don't require them.

Effectively, it bypasses the issue discussed in this review thread.

[tgross35]

I believe @RalfJung is the expert on how these attributes interact

[RalfJung]

The idea was that you'd just mark those functions as rustc_const_unstable. What you describe sounds like a non-trivial amount of infrastructure, I don't think that's worth it.

The attribute you point to isn't even needed since that function has a const-stable interior.

[RalfJung]

In particular it would seem like your proposal requires the same amount of annotations? It's just forward_unstable instead of const_unstable. So I so not see the benefit.