3 ms·

> My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Please file bugs against the Rust c

> My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Please file bugs against the Rust compiler then, because that would be a serious violation of the compatibility rules!

burntsushi 8y ago
It's definitely a thing. It's easier to see with applications that use a lock file rather than libraries that always try to fetch the latest dependencies. That's because there have been incompatible changes made, but within the "allowed breakage" policy. For example, try checking out 0.2.0 or 0.3.0 of ripgrep and building it with Rust 1.33. Both fail for different reasons. The former fails because rustc-serialize 0.3.19 was using an irrefutable pattern in a method without a body, and this was prohibited: https://github.com/rust-lang/rust/pull/37378 https://github.com/rust-lang/rust/pull/37378 However, if you run `cargo update` first, then the build succeeds. The 0.3.0 checkout fails because of a change in Cargo. Specifically, I think it used to define OUT_DIR while compiling the build script, but this was not intentional. It was only supposed to be set when running the build script. ripgrep 0.3.0 got caught here in the time after when the bug was introduced but before it was fixed. See: https://github.com/rust-lang/cargo/issues/3368 https://github.com/rust-lang/cargo/issues/3368 In this case, cargo update doesn't solve this. You cannot build ripgrep 0.3.0 with any recent version of the compiler. You need to go back to a version of the Rust distribution which ships a Cargo version that sets OUT_DIR when compiling build scripts. (Or, more likely, patch build.rs since it's a trivial fix.) Of course, both of these things are fine on their own. But strictly speaking, from a user experience point of view, code does break from time to time. With that said, ripgrep 0.4.0 and newer all compile on Rust 1.33, and ripgrep 0.4.0 was released over two years ago. So, strictly speaking, it does show the GP is wrong in at least some circumstances. :-)
paulddraper 8y ago
Unfortunately, I don't know enough to rewind history and do enough archaeology to find out whose "fault" it is. But as a possible example, typemap [1] which is a library featured on Awesome Rust [2] ("curated list of Rust code and resources"). Project uses cargo. Has a lock file with two deps. Last code commit was May 2017. And I can't get it to compile. [1] https://github.com/reem/rust-typemap https://github.com/reem/rust-typemap [2] https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust
- steveklabnik 8y ago
  What error do you get?
- pcwalton 8y ago
  There's no lock file in that project. But moreover, you stumbled upon one of the worst cases, a soundness problem that has yielded a lot of discussion because of that crate specifically: https://github.com/rust-lang/rust/issues/50781 https://github.com/rust-lang/rust/issues/50781 The issue here is that the typemap crate was found to be relying on a compiler bug. The compiler bug could be exploited to write transmute in safe code: in other words, all the safety guarantees of Rust go out the window unless we break that crate. It's a bad situation, but I don't know what we could have done differently. I think everyone agrees it's not worth sacrificing all the safety properties of Rust to keep typemap building.
est31 8y ago
This has less something to do with Rust itself but the ecosystem, but once I updated my system and obtained a newer version of openssl on my OS. Sadly, some of my projects still used an older version of the openssl crate somewhere inside their crate tree. The openssl-sys crate author chose to check that the native library version it was compiled against was below a certain version, so it broke. All requests by users to fix the legacy bug were deflected with the mantra "go update the openssl crate the fixed version is out since a year already"... https://github.com/sfackler/rust-openssl/issues/994 https://github.com/sfackler/rust-openssl/issues/994 https://github.com/sfackler/rust-openssl/pull/1001 https://github.com/sfackler/rust-openssl/pull/1001
drbawb 8y ago
My project stopped building on compilers w/ the new module system. I did file an issue (56247, see also 56317) and was told it won't be fixed. The fix to my dependency was trivial, but it did stop my code from compiling with no change to my Cargo.toml/Cargo.lock, and ultimately it did require me to unpin that crate's version and update it. My understanding was that by virtue of my project not having the edition 2018 key I would have been isolated from such changes to the language.

burntsushi 8y ago

It's definitely a thing. It's easier to see with applications that use a lock file rather than libraries that always try to fetch the latest dependencies. That's because there have been incompatible changes made, but within the "allowed breakage" policy. For example, try checking out 0.2.0 or 0.3.0 of ripgrep and building it with Rust 1.33. Both fail for different reasons. The former fails because rustc-serialize 0.3.19 was using an irrefutable pattern in a method without a body, and this was prohibited: https://github.com/rust-lang/rust/pull/37378 https://github.com/rust-lang/rust/pull/37378 However, if you run `cargo update` first, then the build succeeds. The 0.3.0 checkout fails because of a change in Cargo. Specifically, I think it used to define OUT_DIR while compiling the build script, but this was not intentional. It was only supposed to be set when running the build script. ripgrep 0.3.0 got caught here in the time after when the bug was introduced but before it was fixed. See: https://github.com/rust-lang/cargo/issues/3368 https://github.com/rust-lang/cargo/issues/3368 In this case, cargo update doesn't solve this. You cannot build ripgrep 0.3.0 with any recent version of the compiler. You need to go back to a version of the Rust distribution which ships a Cargo version that sets OUT_DIR when compiling build scripts. (Or, more likely, patch build.rs since it's a trivial fix.) Of course, both of these things are fine on their own. But strictly speaking, from a user experience point of view, code does break from time to time. With that said, ripgrep 0.4.0 and newer all compile on Rust 1.33, and ripgrep 0.4.0 was released over two years ago. So, strictly speaking, it does show the GP is wrong in at least some circumstances. :-)

paulddraper 8y ago

Unfortunately, I don't know enough to rewind history and do enough archaeology to find out whose "fault" it is. But as a possible example, typemap [1] which is a library featured on Awesome Rust [2] ("curated list of Rust code and resources"). Project uses cargo. Has a lock file with two deps. Last code commit was May 2017. And I can't get it to compile. [1] https://github.com/reem/rust-typemap https://github.com/reem/rust-typemap [2] https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust

steveklabnik 8y ago
What error do you get?
pcwalton 8y ago
There's no lock file in that project. But moreover, you stumbled upon one of the worst cases, a soundness problem that has yielded a lot of discussion because of that crate specifically: https://github.com/rust-lang/rust/issues/50781 https://github.com/rust-lang/rust/issues/50781 The issue here is that the typemap crate was found to be relying on a compiler bug. The compiler bug could be exploited to write transmute in safe code: in other words, all the safety guarantees of Rust go out the window unless we break that crate. It's a bad situation, but I don't know what we could have done differently. I think everyone agrees it's not worth sacrificing all the safety properties of Rust to keep typemap building.

est31 8y ago

This has less something to do with Rust itself but the ecosystem, but once I updated my system and obtained a newer version of openssl on my OS. Sadly, some of my projects still used an older version of the openssl crate somewhere inside their crate tree. The openssl-sys crate author chose to check that the native library version it was compiled against was below a certain version, so it broke. All requests by users to fix the legacy bug were deflected with the mantra "go update the openssl crate the fixed version is out since a year already"... https://github.com/sfackler/rust-openssl/issues/994 https://github.com/sfackler/rust-openssl/issues/994 https://github.com/sfackler/rust-openssl/pull/1001 https://github.com/sfackler/rust-openssl/pull/1001

drbawb 8y ago

My project stopped building on compilers w/ the new module system. I did file an issue (56247, see also 56317) and was told it won't be fixed. The fix to my dependency was trivial, but it did stop my code from compiling with no change to my Cargo.toml/Cargo.lock, and ultimately it did require me to unpin that crate's version and update it. My understanding was that by virtue of my project not having the edition 2018 key I would have been isolated from such changes to the language.