--print option to list available feature gates

[zackmdavis]

The option is only made available on nightly builds, for the obvious
reason. While we're here, also prevent the unstable target-spec-json
(tracking issue #38338) from showing up in the --help on stable builds
(although the way in which we accomplish this is slightly clumsy for
lifetime reasons, as noted in the FIXME).

We make REMOVED_FEATURES, ACCEPTED_FEATURES, &c. public for consistency,
even though the functionality at issue only needs ACTIVE_FEATURES.

The UI test will add a little bit of friction for future feature
developers, but it's better than under-testing.

Resolves #38768.

[rust-highfive]

r? @eddyb

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

[eddyb]

r? @alexcrichton

[alexcrichton]

Thanks for the PR! I'm not personally entirely sold on the motivation here as nothing here is stable, so you can't really do feature detection at all. The meaning of a feature foo can change over time and the actual dependency of code is not on a feature foo but rather foo plus a number of bugs being fixed.

@joshtriplett I wonder if may you have some thoughts on this as the original reporter?

[joshtriplett]

It'd be nice if at least the list of stable features was available in stable...

[alexcrichton]

@zackmdavis do you have thoughts on @joshtriplett's last comment?

[zackmdavis]

I guess I was sort of thinking about this more in terms of, "Given that this nightly compiler knows how to accept feature flags, it should also know how to list them, because that seems like an obvious thing that a user might be curious about that we can answer without forcing them to read the source code."

[alexcrichton]

As I explained above though there's no actual meaning to listing unstable features. The definition of an unstable feature changes over time and so you have to read the source anyway.

[carols10cents]

@joshtriplett:

It'd be nice if at least the list of stable features was available in stable...

There are stable features...? confused I thought once something was stable, it wasn't a feature anymore....

@alexcrichton are you saying you're against landing this change?

[alexcrichton]

Yes I am against landing this as-is, personally.

[carols10cents]

@alexcrichton what changes would make you in favor of landing this?

[joshtriplett]

@carols10cents It's still a feature, just not a feature-gated one.

[zackmdavis]

As I explained above though there's no actual meaning to listing unstable features.

That sounds a little exaggerated to me: surely "Beware; the behavior or scope of this feature flag could change" (e.g., like how stmt_expr_attributes used be needed for any attributes on non-item statements or expressions, but now only for expressions) isn't the same as "It is literally meaningless to speak of 'the same' feature flag in different nightly compilers"?

I thought once something was stable, it wasn't a feature anymore....

The compiler does know about "accepted" features (and this was put to use in diagnostics at least previously), but I think the case for "It's meaningless to talk about this" is stronger here—after the feature has been accepted, it's indistinguishable from any other part of the language (in contrast to "active", unaccepted features activating some identifiable branches of code, even if that code can change from nightly to nightly).

[kennytm]

commented 7 days ago

Hi @alexcrichton @joshtriplett @zackmdavis @carols10cents,

What is the expectation of this PR, should it be closed, or reworded for merging, or be nominated to a team (T-docs?) for further discussion?

[bors]

☔ The latest upstream changes (presumably #45666) made this pull request unmergeable. Please resolve the merge conflicts.

[zackmdavis]

@kennytm I think the people already in this thread have said what they have to say; I leave it to your judgment whether to close or summon the docs team for more input.

[kennytm]

cc @rust-lang/docs then.

Personally I think this feature is not harmful, as we already have the unstable book, but this is not useful either as the library features (e.g. try_trait) are not listed.

[eddyb]

I think we should've long stopped keeping removed feature gates in the compiler.
AFAIK we don't keep stabilized library features around, so why are language features different?
cc @rust-lang/compiler

[shepmaster]

In the interest of moving this forward, I've picked a team and nominated it to be discussed at the next meeting. Y'all are welcome to change the team, of course.

[zackmdavis]

Hm, on second thought, the lack of enthusiasm (this patch doesn't meet the original reporter's satisfaction; I only wrote this patch because it seemed like a cool thing the compiler might as well be able to do; I don't actually need to use it for anything) makes me think we should close.