Editions and generated code

[CAD97]

Generated code (the kind that you generate in build.rs) is in an interesting spot in terms of edition changes. Obviously, if the generated code uses features like async blocks, it’ll have to require the new edition, as those are (unfortunately) impossible to express in the 2015 edition.

But for smaller quality-of-life changes in behavior, such as the path changes, generated code is in the unenviable spot of wanting to generate code that works in either edition. (For current stable compilers, the same applies to procedural macro-generated code with Span::call_site, IIRC.)

Would it make sense to add a #[edition = "2018"] attribute such that modules can specify a different edition from the crate default? This would allow generated modules at least to start with #![edition = "2018"] and not worry about the edition of the crate they’re generating code for.

This would also help large crates where rustfix doesn’t quite cover everything to do a slower more piecewise conversion. Or is this too much risk? Either way we should probably record somewhere best practices for code generating into an unknown edition, and keep that use case in mind for future edition changes.

[steveklabnik]

There should be a way to generate code that works in 2015, and works in 2018, where the 2018 version produces warnings. So if you generate the code with #![allow(warnings)], that should work.

[mark-i-m]

So my understanding is that internally the compiler already tracks editions on a per-span basis. This is why you can call a macro from edition 2018 in edition 2015 and vice versa. I would expect that proc-macros and custom-derives work the same.