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

Many feature gates are not checked in macros #18102

Closed
brson opened this issue Oct 16, 2014 · 6 comments · Fixed by #20190
Closed

Many feature gates are not checked in macros #18102

brson opened this issue Oct 16, 2014 · 6 comments · Fixed by #20190
Milestone

Comments

@brson
Copy link
Contributor

brson commented Oct 16, 2014

Feature gates are generally checked before expansion so feature gates are defeated by code inside macros.

@alexcrichton
Copy link
Member

Notably, this compiles today when it shouldn't:

fn main() {
    let a = ('a', 1u);
    println!("{}", a.0);
}

@pnkfelix
Copy link
Member

P-backcompat-lang, 1.0

@pnkfelix pnkfelix added this to the 1.0 milestone Oct 16, 2014
@aturon
Copy link
Member

aturon commented Oct 16, 2014

Note that we may be able to use a technique similar to that for the stability lint: #17286

@japaric
Copy link
Member

japaric commented Oct 16, 2014

This is a duplicate of #12122

@alexcrichton
Copy link
Member

While somewhat similar I don't think that this is a dupe of #12122. The definition of a macro should be subject to the feature gates in the defining crate, but the usage of a macro should be subject to the feature gates in the consumer crate.

#12122 indicates that we don't check macro definitions, and this indicates that we don't check macro invocations.

@emberian
Copy link
Member

I think the best we can do right now is check after the expansion of macros, in the stable channel. Outside of the stable channel, this might cause some undesirable noise when the used features are supposed to be "internal implementation details" of a lib, but I think that sort of claim is baloney because the feature could disappear at any moment. It ought to require work on the macro user's part if it could stop working at any moment due to a compiler upgrade.

bors added a commit that referenced this issue Jan 1, 2015
Uses the same approach as #17286 (and
subsequent changes making it more correct), where the visitor will skip any
pieces of the AST that are from "foreign code", where the spans don't line up,
indicating that that piece of code is due to a macro expansion.

If this breaks your code, read the error message to determine which feature
gate you should add to your crate.

Closes #18102

[breaking-change]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants