And I guess it’s 2015 edition, because it’ll fail in 2018 edition Rust: where the 2015 edition has ::u8(0u8), the 2018 edition will need you to write crate::u8(0u8) or self::u8(0u8), since only crates exist at the top level now, rather than the contents of the current crate as well.
Yeah it's indeed the 2015 edition because while compiletest watches for // edition:something comments [0] (like this [1]), it doesn't pass any edition flag to the compiler if no such comment is present, and the rust compiler defaults to the 2015 edition if none was specified.
However, the compiler has to continue to be able to compile 2015 edition code, as it is still guaranteed to work and be intermixable with 2018 (and soon, 2021) code in the same application.
For curious people unfamiliar with the situation with this: Rust cares about backwards-compatibility so that you should still be able to compile code from 2015 in 2042 (some libraries are just stable!), but it also wants to allow certain changes to the language that you might think would be backwards-incompatible. Each crate (library) declares an edition, and the compiler follows the rules of that edition, and then you can link all the different crates together without worrying what edition they were written in. Editions are limited in what they can change, because things like traits are shared between crates, so they can’t be changed in editions; it’s mostly syntactic stuff, like the 2018 edition making async/await keywords and making dyn a full (rather than conditional) keyword.
I'm not very knowledgeable with how compilers or language standards work, but would there not be security implications with this approach?
For example let's say a security exploit surfaces in the 2015 edition of Rust, would that not mean all the libraries declared as 2015 edition would have to be updated or abandoned in that case?
Or now that I think about it, is it instead the case that a whole program including all dependencies will be compiled by the same compiler (of which newer editions will have the latest security fixes), just that the compiler will always have to support compiling programs using legacy syntax when it identifies the crate's edition?
It's just syntax differences. The newer compiler supports all previous language editions, you're not using a 2015-era compiler to compile 2015 edition code.
Rust is not ABI-stable, there is no guarantee that you can even mix libs built with different versions of the compiler. The entire Rust tooling is built around static linking and building all your dependencies from sources. So yes, all the crates that go into your program are built with the same compiler, it's just that the compiler knows how to paper over the syntax differences in the different language editions.
> Or now that I think about it, is it instead the case that a whole program including all dependencies will be compiled by the same compiler (of which newer editions will have the latest security fixes)
It's this. Rust doesn't (yet) have a stable ABI for functions that aren't marked `extern "C"`. Any security vulnerability that would affect code in rust-lang/rust would most likely be in the standard library, which doesn't change between editions. All code links to the same libstd. Only the compiler frontend changes
JavaScript had something close, valid on the context level, with "use strict" (which is, I guess, borrowed from Perl), and I still don't understand why they don't repeat that for newer features that would be much simpler if they broke backwards compatibility.
Well, the ability to specify python version by module would've made migration much easier for everyone (in theory). But you're quite right that it wouldn't by itself be a solution -- it would also have required additional complexity to handle interoperability when calling between python versions, both in the runtime and the programs themselves (even a sufficiently smart compiler can't figure out what string encoding a python2 function expects).
