6 ms·

I have no idea what I am reading

by skohan 5y ago

phaylon 5y ago
It's the part of the Rust compiler test suite that makes sure odd syntactical combinations still behave as they are supposed to.
- chrismorgan 5y ago
  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.
  - Macha 5y ago
    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.
    - chrismorgan 5y ago
      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.
      - peterkelly 5y ago
        This is what Python should have done.
        egeozcan 5y ago
        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.
        Macha 5y ago
        Didn't this end up in every Perl file having a ton of different "use" statements at the top for features that became expected?
        egeozcan 5y ago
        Perl model of enabling features individually was indeed too much, I was suggesting a language-level switch.
        winstonewert 5y ago
        This approach only works for syntax level changes, it wouldn't have helped the problematic changes in Python 2 -> 3.
        cyphar 5y ago
        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).
      - fat-chunk 5y ago
    - iudqnolq 5y ago
      There's even a handy macro for switching between them /s https://twitter.com/m_ou_se/status/1392200805168689154 https://twitter.com/m_ou_se/status/1392200805168689154
  - phaylon 5y ago
    Yeah. I'd assume a 2018 specific one would show up below https://github.com/rust-lang/rust/tree/master/src/test/ui/rust-2018 https://github.com/rust-lang/rust/tree/master/src/test/ui/ru... if needed.
  - est31 5y ago
    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. [0]: https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d8f8e31c05f681e61a10/src/tools/compiletest/src/header.rs#L439 https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d... [1]: https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d8f8e31c05f681e61a10/src/test/ui/editions/edition-imports-2018.rs https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d...
berkes 5y ago
Me neither. But I'd guess it's to test (or explain, or document) edge-cases or unexpected behaviour when using Rust std.
- Minor49er 5y ago
  I've seen those sorts of things in other languages, though they're often accompanied by explanatory comments, if not a separate document. Given that these appear to be in a test suite for Rust itself, I'm surprised that these aren't explained in the code (at least as far as I saw)

I have no idea what I am reading

by skohan 5y ago

I have no idea what I am reading

It's the part of the Rust compiler test suite that makes sure odd syntactical combinations still behave as they are supposed to.

chrismorgan 5y ago
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.
- Macha 5y ago
  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.
  - chrismorgan 5y ago
    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.
    - peterkelly 5y ago
      This is what Python should have done.
      - egeozcan 5y ago
        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.
        Macha 5y ago
        Didn't this end up in every Perl file having a ton of different "use" statements at the top for features that became expected?
        egeozcan 5y ago
        Perl model of enabling features individually was indeed too much, I was suggesting a language-level switch.
      - winstonewert 5y ago
        This approach only works for syntax level changes, it wouldn't have helped the problematic changes in Python 2 -> 3.
        cyphar 5y ago
        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).
    - fat-chunk 5y ago
  - iudqnolq 5y ago
    There's even a handy macro for switching between them /s https://twitter.com/m_ou_se/status/1392200805168689154 https://twitter.com/m_ou_se/status/1392200805168689154
- phaylon 5y ago
  Yeah. I'd assume a 2018 specific one would show up below https://github.com/rust-lang/rust/tree/master/src/test/ui/rust-2018 https://github.com/rust-lang/rust/tree/master/src/test/ui/ru... if needed.
- est31 5y ago
  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. [0]: https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d8f8e31c05f681e61a10/src/tools/compiletest/src/header.rs#L439 https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d... [1]: https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d8f8e31c05f681e61a10/src/test/ui/editions/edition-imports-2018.rs https://github.com/rust-lang/rust/blob/69b352ef7749825abde2d...

berkes 5y ago

Me neither. But I'd guess it's to test (or explain, or document) edge-cases or unexpected behaviour when using Rust std.

Minor49er 5y ago
I've seen those sorts of things in other languages, though they're often accompanied by explanatory comments, if not a separate document. Given that these appear to be in a test suite for Rust itself, I'm surprised that these aren't explained in the code (at least as far as I saw)