3 ms·

> We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwa

by Lorkki 5y ago

> We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.

capitol_ 5y ago
It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219 https://github.com/cortex/ripasso/issues/219
- eldruin 5y ago
  This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
  - zibzab 5y ago
    A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago. A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.
    - couchand 5y ago
      Depends on the architecture: ARM for instance is a tier 1 target and you can use stable.
      - steveklabnik 5y ago
        This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)
        couchand 5y ago
        Good point. Though you can always link to .S for that last bit, right? I don't mean to tell you your business, I know you folks are doing much more intense stuff than I am. It doesn't surprise me that you'd know exactly what's keeping you from using stable.
        steveklabnik 5y ago
        It's all good, you're not wrong! It would just add a lot of complexity to the build for not a ton of gain...
  - capitol_ 5y ago
    No, it's on stable rust, maybe you got confused by the bug report talking about the nixos-unstable channel, that has nothing to do with the rust nightly builds, it's the version of nixos that is currently under development. You can reproduce this yourself with: git clone https://github.com/cortex/ripasso.git cd ripasso git checkout release-0.5.1 cargo build --locked On my arch system this fails to build with the same errors as the bug report i got, and my rustc version is: $ rustc --version --verbose rustc 1.57.0 (f1edd0429 2021-11-29) binary: rustc commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c commit-date: 2021-11-29 host: x86_64-unknown-linux-gnu release: 1.57.0 LLVM version: 13.0.0
zibzab 5y ago
IIRC last time we had issues it was something in the core libraries, not the compiler. I think it was something as fundamental as Error being changed or moved around.
- eldruin 5y ago
  You may have started getting deprecation warnings because some methods in the `Error` trait have been deprecated [1] in favor of a different mechanism. Then, you may have configured warnings to result in compilation errors in your build/project, however, I would argue this situation is not what most people would understand as "code not compiling due to a compiler update". [1]: https://doc.rust-lang.org/std/error/trait.Error.html https://doc.rust-lang.org/std/error/trait.Error.html
  - zibzab 5y ago
    In my case it failed to build, maybe it was a different problem, maybe the compiler had at some point emitted errors instead of warnings. I don't remember and it doesn't really matter other than we had build issues and it was unexpected.
    - steveklabnik 5y ago
      Deprecation should be the only change to Error in the last six years. It hasn’t moved. If you ever get a repro would love to hear about it! This kind of thing doesn’t happen at the scale we’re at anymore, if it did there would be an uproar.

by Lorkki 5y ago

capitol_ 5y ago

It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219 https://github.com/cortex/ripasso/issues/219

eldruin 5y ago
This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
- zibzab 5y ago
  A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago. A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.
  - couchand 5y ago
    Depends on the architecture: ARM for instance is a tier 1 target and you can use stable.
    - steveklabnik 5y ago
      This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)
      - couchand 5y ago
        Good point. Though you can always link to .S for that last bit, right? I don't mean to tell you your business, I know you folks are doing much more intense stuff than I am. It doesn't surprise me that you'd know exactly what's keeping you from using stable.
        steveklabnik 5y ago
        It's all good, you're not wrong! It would just add a lot of complexity to the build for not a ton of gain...
- capitol_ 5y ago
  No, it's on stable rust, maybe you got confused by the bug report talking about the nixos-unstable channel, that has nothing to do with the rust nightly builds, it's the version of nixos that is currently under development. You can reproduce this yourself with: git clone https://github.com/cortex/ripasso.git cd ripasso git checkout release-0.5.1 cargo build --locked On my arch system this fails to build with the same errors as the bug report i got, and my rustc version is: $ rustc --version --verbose rustc 1.57.0 (f1edd0429 2021-11-29) binary: rustc commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c commit-date: 2021-11-29 host: x86_64-unknown-linux-gnu release: 1.57.0 LLVM version: 13.0.0

zibzab 5y ago

IIRC last time we had issues it was something in the core libraries, not the compiler. I think it was something as fundamental as Error being changed or moved around.

eldruin 5y ago
You may have started getting deprecation warnings because some methods in the `Error` trait have been deprecated [1] in favor of a different mechanism. Then, you may have configured warnings to result in compilation errors in your build/project, however, I would argue this situation is not what most people would understand as "code not compiling due to a compiler update". [1]: https://doc.rust-lang.org/std/error/trait.Error.html https://doc.rust-lang.org/std/error/trait.Error.html
- zibzab 5y ago
  In my case it failed to build, maybe it was a different problem, maybe the compiler had at some point emitted errors instead of warnings. I don't remember and it doesn't really matter other than we had build issues and it was unexpected.
  - steveklabnik 5y ago
    Deprecation should be the only change to Error in the last six years. It hasn’t moved. If you ever get a repro would love to hear about it! This kind of thing doesn’t happen at the scale we’re at anymore, if it did there would be an uproar.