5 ms·

If the problem really comes from incorrect code in Firefox then I don't think that backwards compatibility is even possible. Consider the possibility that it wa

If the problem really comes from incorrect code in Firefox then I don't think that backwards compatibility is even possible. Consider the possibility that it was actually a bug in the Rust compiler that let this code pass. What should the compiler developers do if not fix this bug? If, on the other hand, the code was correct, then backwards compatibility is definitely expected. The same holds for the format of the cargo files, btw. changing something like this during one major (or minor, depending on the release cycle) release is bad form IMO. The mentioned case of C compilers and their warnings is an interesting grey area. Presumably it would still compile just fine, but as a developer you want -Werror and -Wall. In practice this often makes certain libraries incompatible after a compiler upgrade.

dathinab 5y ago
There had been a few cases where bugs in Rust had been fixed which did cause breakage, but fixes where rolled out slowly spread over multiple versions. This included: - Soundness issues around Self: Sized bound requirements and traits. (Big breakage bout early one in rust lifetime.) - Soundness issues around something related to match statements and guards I don't remember. - Something related to accepting invalid inputs, I think this included Cargo accepting invalid Cargo.toml files. There was also a very small bit of accidental breakage which counted as a bug but affected close to no one so no one ever invested time to fix. For example a bug which only affects people running multiple tightly linked rust crates on older editions and doing unusual stuff wrt. macro imports and re-exports which where only valid for I think 1-2 rust version. Then there was a bit of accidental stabilization, where things which should not be doable on stable where doable. If not found very early this was normally kept stable if possible, but I think there was at least one time where this "stabilization bug" needed to be fixed. Anyway to cut it short: 1) Compilers are not perfect, this is also true for C/C++. 2) At least serve bugs (e.g. soundness bugs) are not treated as "de-facto" standardized/stabilized but are fixed (something I prefer). ---- As a side note Firefox is a bad example as they used some tricks to use some definitely not stable options on stable rust which is basically guaranteed to cause breakage at some point and not covered by any stability guarantees. As another side note `#[deny(warnings)]` is also not covered by stability guarantees, the compiler is free to add new warnings any time (but will do so with a lot of care, e.g. preferably only with new rust editions, which also may make some warnings errors). --- Also: -`rustup` supports setting overrides, no reason to fear updates, just pin a older rust version in your create using overrides (if you need to). - Idk. about his problems but I have yet to see a case where any breakage wasn't reasonable straight forward to fix (weather unintentional, intentional to fix soundness or due to an edition change triggered by me).
- gpderetta 5y ago
  These days upgrades go much more smoothly, but on the first decade of the millennium upgrading your C++ compiler was always a major hassle as each version would fix many bugs, increase its standard compliance and start rejecting erroneous code.
  - aseipp 5y ago
    It still happens today, but nowhere near as badly. I package FoundationDB for my linux distribution, and around GCC 6.x the build broke for version FDB 6.0. Why? Because the code used 'log' unqualified in their code (for logging), and some rearrangement of the libstdc++ headers to be more correct and caused the 'log' (math function) to come into scope. (The libstdc++ changes were the correct course of action, in my reading.) Of course, FDB also changed their code in the mean time so newer versions 6.1+ didn't hit this, so it was an old regression in an old version from a mishap in the standard library that had been a bug for like, years and years. Tons of regressions like this happen all the time in the GCC/LLVM world. Every time we do a bump of the default C compiler, you can bet it will take 4-8 weeks while regressions -- from "This random thing enabled -Werror, again" to "Someone used a new feature but scoped the #ifdef wrong" to "Actual segfaults in libstdc++" -- are sorted out.

dathinab 5y ago

There had been a few cases where bugs in Rust had been fixed which did cause breakage, but fixes where rolled out slowly spread over multiple versions. This included: - Soundness issues around Self: Sized bound requirements and traits. (Big breakage bout early one in rust lifetime.) - Soundness issues around something related to match statements and guards I don't remember. - Something related to accepting invalid inputs, I think this included Cargo accepting invalid Cargo.toml files. There was also a very small bit of accidental breakage which counted as a bug but affected close to no one so no one ever invested time to fix. For example a bug which only affects people running multiple tightly linked rust crates on older editions and doing unusual stuff wrt. macro imports and re-exports which where only valid for I think 1-2 rust version. Then there was a bit of accidental stabilization, where things which should not be doable on stable where doable. If not found very early this was normally kept stable if possible, but I think there was at least one time where this "stabilization bug" needed to be fixed. Anyway to cut it short: 1) Compilers are not perfect, this is also true for C/C++. 2) At least serve bugs (e.g. soundness bugs) are not treated as "de-facto" standardized/stabilized but are fixed (something I prefer). ---- As a side note Firefox is a bad example as they used some tricks to use some definitely not stable options on stable rust which is basically guaranteed to cause breakage at some point and not covered by any stability guarantees. As another side note `#[deny(warnings)]` is also not covered by stability guarantees, the compiler is free to add new warnings any time (but will do so with a lot of care, e.g. preferably only with new rust editions, which also may make some warnings errors). --- Also: -`rustup` supports setting overrides, no reason to fear updates, just pin a older rust version in your create using overrides (if you need to). - Idk. about his problems but I have yet to see a case where any breakage wasn't reasonable straight forward to fix (weather unintentional, intentional to fix soundness or due to an edition change triggered by me).

gpderetta 5y ago
These days upgrades go much more smoothly, but on the first decade of the millennium upgrading your C++ compiler was always a major hassle as each version would fix many bugs, increase its standard compliance and start rejecting erroneous code.
- aseipp 5y ago
  It still happens today, but nowhere near as badly. I package FoundationDB for my linux distribution, and around GCC 6.x the build broke for version FDB 6.0. Why? Because the code used 'log' unqualified in their code (for logging), and some rearrangement of the libstdc++ headers to be more correct and caused the 'log' (math function) to come into scope. (The libstdc++ changes were the correct course of action, in my reading.) Of course, FDB also changed their code in the mean time so newer versions 6.1+ didn't hit this, so it was an old regression in an old version from a mishap in the standard library that had been a bug for like, years and years. Tons of regressions like this happen all the time in the GCC/LLVM world. Every time we do a bump of the default C compiler, you can bet it will take 4-8 weeks while regressions -- from "This random thing enabled -Werror, again" to "Someone used a new feature but scoped the #ifdef wrong" to "Actual segfaults in libstdc++" -- are sorted out.