Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command-line option to list supported feature-gate names #38768

Closed
joshtriplett opened this issue Jan 2, 2017 · 6 comments
Closed

Command-line option to list supported feature-gate names #38768

joshtriplett opened this issue Jan 2, 2017 · 6 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@joshtriplett
Copy link
Member

I'd like to have a command-line option to list all the supported feature-gate names in rustc. This would simplify the job of tools that want to detect the features supported by the installed version of rustc.

I don't know if introducing an option like this would require an RFC, or just a patch. Posting this as an issue to find that out before working on a patch.

@hanna-kruppe
Copy link
Contributor

Is this about language features, library features, or both?

@est31
Copy link
Member

est31 commented Jan 2, 2017

I'm not sure whether this is what you want, but do you know of the output of x.py src/tools/tidy?

@joshtriplett
Copy link
Member Author

@rkruppe Both, for as long as std and rustc remain coupled. Anything supported in a feature(...) declaration.

@joshtriplett
Copy link
Member Author

joshtriplett commented Jan 2, 2017

@est31 I didn't. (I've seen that output before, just not the tool that generated it; thanks!) That would work, if available as a runtime option rather than a build-time command.

@hanna-kruppe
Copy link
Contributor

Language features are listed in librustc/middle/lang_items.rs. Library features are a bit more difficult to enumerate because they're spread in annotations all over multiple crates (e.g., for the compiler to even know about the test feature, it must look at the test crate). Still, it ought to be feasible to load all relevant crates for --print features because the set is fixed and quite small. After all, third party crates can't (at least really really shouldn't) have stability annotations.

One wrinkle with the tidy tool is that it crawls the source code. So one would have to include its output into the binary as a static string, gross! Besides, it lists feature flags that aren't relevant to the current target. For example, on linux it lists various windows_* library features which are only applied to stuff behind a cfg(unix). This is the right choice for development but probably not for "what feature flags can I set?".

@Mark-Simulacrum Mark-Simulacrum added the A-frontend Area: Compiler frontend (errors, parsing and HIR) label May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
zackmdavis added a commit to zackmdavis/rust that referenced this issue Oct 12, 2017
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 rust-lang#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 rust-lang#38768.
@steveklabnik
Copy link
Member

#45223 was supposed to close this, but github didn’t for some reason. Closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

5 participants