Macros bypass other feature gates

[brson]

This uses the log_syntax! macro without the log_syntax feature gate:

#[feature(macro_rules)];
// This should be required
// #[feature(log_syntax)];

macro_rules! hey ( () => { log_syntax!() } )

fn main() {
    hey!()                                                                                         
}

Nominating.

[alexcrichton]

This will likely require an overhaul of the feature_gate infrastructure to process the AST after expansion, not before. You then run into fun things like use std::prelude::*; shouldn't be gated and neither should #[phase(link, syntax)] extern mod std;

[alexcrichton]

Hm, and that won't necessarily work because macro invocations no longer exist in the ast after expansion. This may be a little though.

[sfackler]

It's a bit hacky, but we can always just run feature gating before and after expansion like we already do with cfg processing.

[sfackler]

It'd require a bit of trickyness since std-injection uses #[phase(syntax, link)]. Maybe it's finally time to get #[feature(..)] working in places other than the crate root.

[glaebhoerl]

I feel like the check should happen where the macro is declared, not where it's used. (Currently neither happens of course, which is definitely wrong.)

[lilyball]

Feature gating after expansion means that clients of your macro will have to turn on feature gates even though they aren't using those features themselves. I feel like clients of a macro should not have to suffer the burden of dealing with this, especially as they only way they'll even know what gates to turn on is to compile, fail, and read the error message.

Is there any way the feature gating machinery could read the macro definition and see the problem there?

[sfackler]

That would be hard for macro_rules macros and impossible for procedural macros. If #[feature(..)] were changed so that it could be attached to anything, the definition could be adjusted to

macro_rules! hey ( () => { #[feature(log_syntax)] log_syntax!() } )

and then rustc could run feature gating before and after expansion. It'd clutter up macros a bit though.

[lilyball]

Could the macro embed information about what feature gates are in effect at its definition, and then mark the generated AST with that same feature gate information?

[sfackler]

That'd be doable, but it'd have to be a manual opt-in thing by the macro author.

[sfackler]

It'd also preferably be mixed with properly scoped #[feature] support.

[pnkfelix]

This definitely blocks unfeature-gating macro_rules! for 1.0.

But it is technically not otherwise a 1.0 blocker.

Yes it seems like enough of a trap to assign P-high; so that's what we're doing.