[WIP] Require specific feature names in #[allow_internal_unstable].

[eddyb]

I opened this with just a hacky commit to test the perf impact of one implementation strategy.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

@bors try

[bors]

⌛ Trying commit af5cce1 with merge 389686a...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[eddyb]

@rust-timer build 389686a

[rust-timer]

Success: Queued 389686a with parent f55129d, comparison URL.

[eddyb]

We either don't have expansion stress tests... or I'm good to go.
cc @nikomatsakis @petrochenkov

[pnkfelix]

@eddyb what is the next step here? Can you link this back to the relevant bug that sparked this investigation?

[petrochenkov]

Can you link this back to the relevant bug that sparked this investigation?

+1, I'm mildly skeptical about this, why isn't a boolean flag enough?

[TimNN]

Ping from triage @eddyb: It looks like some clarifications have been requested for this PR.

[TimNN]

Ping from triage @eddyb: What are your plans for this PR?

[TimNN]

Ping from triage, @eddyb! This PR hasn't seen any updates in a while, so I'm closing it for now, per our guidelines. Thanks for your contributions and please feel free to re-open in the future.

[eddyb]

The investigation was actually flawed, we'd need to also support library features, and those aren't a finite set, so they'd have to use Vec, BTreeSet or something else.

The problem I was considering solving, if at all possible efficiently, is that currently #[allow_internal_unstable] allows all features, which came up in #52011:

const fn feature-gating has to ignore allow_internal_unstable, otherwise panic!() will be usable in constant contexts on stable (which is supposed to be gated).
panic!() needs allow_internal_unstable but not for using the panic entry-point as a const fn.

In general, we might be accidentally allowing too much, and I wanted to limit that.