cfg attributes appear are improperly applied inside of `include!`

[sgrif]

Example to reproduce:

// src/lib.rs
include!("foo.rs");

// foo.rs
#[cfg(feature = "never")]
include!("error.rs");

// error.rs
omg i'm a syntax error

This should successfully compile, but instead will have a syntax error. It should behave identically to what would occur if you inlined the first include!, (which does compile successfully)

// src/lib.rs
#[cfg(feature = "never")]
include!("error.rs");

// error.rs
omg i'm a syntax error

[durka]

I think this is a duplicate of some older issues, essentially the problem is that cfg-stripping and macro expansion do not run in an unbounded loop. cfg is stripped once, then macros, then cfg again, and that's it. So macros which expand to cfg attributes do not work.

[durka]

cf #22250 #30125

[sgrif]

So macros which expand to cfg attributes do not work.

That isn't necessarily correct. That would mean that this would also fail:

// lib.rs
include("foo.rs");

// foo.rs
fn foo() {}

#[cfg(feature = "never")]
fn foo() {}

However, in that case the cfg attr applies completely fine.

[durka]

Hmm, maybe a slightly different problem then. What doesn't work is this:

// lib.rs
include!("foo.rs");

fn main() {}

// foo.rs
fn foo() {}

#[cfg(nope)]
include!("bar.rs");

// bar.rs
fn foo() {}

bar.rs:1:1: 1:12 error: duplicate definition of value `foo` [E0428]
bar.rs:1 fn foo() {}

[sgrif]

Yes. So it appears to specifically be when the cfg attr would affect whether another macro is expanded. As an additional example,

// lib.rs
include!("foo.rs");

fn main() {}

// foo.rs
fn foo() {}

#[cfg(nope)]
mod bar {
    include!("bar.rs");
}

// bar.rs
fn foo() {}

would be fine, but

// lib.rs
include!("foo.rs");

// foo.rs
#[cfg(nope)]
mod bar {
    include!("bar.rs");
}

// bar.rs
omg error

will fail.

[durka]

I think I've said this in past discussions, but if we can't fix the real issue, a band-aid would be to at least output a warning: ignoring cfg attribute or error: found cfg but it's too late (I guess it would have to be a warning for compatibility).

[sgrif]

Just wanted to bump this again, as I lost over an hour to it this afternoon. Turns out struct fields aren't stripped before being passed to derive_Whatever if it goes through this case, meaning #[derive(PartialEq)] completely blows up.

Even just that warning would be a huge help -- however, the macro expansion is actually given more than sufficient information to strip the attributes on its own if need be, so I would think if we can detect that we're ignoring it, we could just fix it there.

[alexcrichton]

In some sense I think include! has and perhaps always will be a bit of a hack in the compiler. This is likely best supported through code generation in the long term as that plumbs through the compiler much more naturally, although I'll admit to also having no idea as to what the underlying issue here is as well unfortunately :(

[jseyfried]

This was fixed in #33706.