include!(...) (still) does not see local variables

[comex]

This is a dupe of #11390 from two years ago; the current behavior appears to be the same, and I just ran into it in my project. That issue was closed as expected behavior, but I don't think the behavior makes any sense.

The contents ofinclude!d files, like the definitions of macros, have a separate hygiene scope and cannot reference local variables by name. However, whereas macros can be granted access to local names by passing them as parameters, include! has no way to pass parameters, so as far as I can tell, included files essentially can't access locals at all. (Wrapping the included file in a macro_rules! declaration doesn't work because the macro name itself is subject to hygiene, so it can't be called. There may be some more complex workaround but I can't figure it out.)

Of course, later-compilation-stage approaches work, like having the include evaluate to a lambda expression which the including code then calls. Alternately, a build script can manually combine the two to produce a file containing the full module, which can then be included or specified with the path attribute on a mod declaration. But both of these have drawbacks and shouldn't be necessary when include! is right there.

Even if the local variable limitation somehow weren't an issue, I'm skeptical that the benefits of hygiene apply to the way include! seems to be typically used in the first place: rarely, and usually as an artifact of the build process, a way to combine checked-in and generated code, rather than as a self-contained abstraction like macros tend to be.

Unfortunately, at this point, changing the behavior of include! would be a breaking change, so I don't propose it. But it would be nice to have some sort of alternate form or argument to the macro that puts the included text in the same hygiene scope as the caller.

[durka]

(Wrapping the included file in a macro_rules! declaration doesn't work because the macro name itself is subject to hygiene, so it can't be called. There may be some more complex workaround but I can't figure it out.)

I don't understand this. Macro names aren't generally subject to hygiene.

[durka]

Would fixing this be a breaking change? It seems like the same kind of change as fixing #31856 would be, which is technically breaking but I don't know whether it counts as a bugfix or not.

Regardless, include!() is basically #include<> from C, which Rust is trying to avoid, so we shouldn't make it too easy to use... ;)

[RReverser]

The entire point of using include! over module for me is generating some file with a build system and inserting it inside of any method of any structure without messing with traits etc. as the source, the Rust is generated from, knows nothing about traits or what it will need from the structure.

Not being able to transparently access scope vars makes it barely different from mod.

[Mark-Simulacrum]

AFAICT include! works today (the test case from #11390 passes, and I recently used this is in a rustc PR as well...)