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

libc and test features are special-cased for feature validity checks #53260

Open
varkor opened this issue Aug 11, 2018 · 4 comments
Open

libc and test features are special-cased for feature validity checks #53260

varkor opened this issue Aug 11, 2018 · 4 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@varkor
Copy link
Member

varkor commented Aug 11, 2018

When implementing #52644, where we emit errors when using unknown features, I had to special case two features: libc and test, because they weren't being picked up (and there were time constraints).

The special-casing is here:

// `stdbuild` has special handling for `libc`, so we need to
// recognise the feature when building std.
// Likewise, libtest is handled specially, so `test` isn't
// available as we'd like it to be.
// FIXME: only remove `libc` when `stdbuild` is active.
// FIXME: remove special casing for `test`.
remaining_lib_features.remove(&Symbol::intern("libc"));
remaining_lib_features.remove(&Symbol::intern("test"));

Ideally these should both not be special-cased. The relevant code for feature collection is in src/librustc/middle/lib_features.rs, so that's a good place to start looking.

@varkor varkor added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Aug 11, 2018
@eddyb
Copy link
Member

eddyb commented Aug 17, 2018

cfg_attr shouldn't make libc special. when we build it in-tree, we set feature = "stdbuild" (which is not set when using it from crates.io).
All you need to do is make sure you're not touching feature-gates in libsyntax{,_ext}, only later on, in librustc.

@varkor
Copy link
Member Author

varkor commented Aug 17, 2018

All you need to do is make sure you're not touching feature-gates in libsyntax{,_ext}

As in: just ignore any warnings for these? Though that means we would avoid the special-casing, it could lead to a build up of unnecessary feature attributes in the compiler.

@eddyb
Copy link
Member

eddyb commented Aug 17, 2018

@varkor I mean, don't check for feature-gating attributes on the AST, only on HIR.

@varkor
Copy link
Member Author

varkor commented Aug 17, 2018

It's been using either hir::itemlikevisit::ItemLikeVisitor or hir::intravisit::Visitor, so that's what it should be doing already, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

No branches or pull requests

2 participants