How to stop Rust code from rotting all the time?

1

I wanted to build a little Rust project whose code was last touched in 2023 and was building and running fine then. It no longer compiles:

$ git pull
Already up to date.

cargo build
   Compiling ...
   Compiling ...
   ...
   Compiling time v0.3.22
error[E0282]: type annotations needed for `Box<_>`
  --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/time-0.3.22/src/format_description/parse/mod.rs:83:9
   |
83 |     let items = format_items
   |         ^^^^^
...
86 |     Ok(items.into())
   |              ---- type must be known at this point
   |
   = note: this is an inference error on crate `time` caused by an API change in Rust 1.80.0; update `time` to version `>=0.3.35` by calling `cargo update`

For more information about this error, try `rustc --explain E0282`.
error: could not compile `time` (lib) due to 1 previous error

OK. I do what the error message suggests:

$ cargo build
   Compiling ...
   Compiling ...
   ...
   Compiling nuid v0.3.2
error[E0432]: unresolved import `rand::distributions`
  --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nuid-0.3.2/src/lib.rs:19:11
   |
19 | use rand::distributions::Alphanumeric;
   |           ^^^^^^^^^^^^^ could not find `distributions` in `rand`

error[E0599]: the method `sample_iter` exists for struct `OsRng`, but its trait bounds were not satisfied
  --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nuid-0.3.2/src/lib.rs:82:27
   |
82 |         for (i, n) in rng.sample_iter(&Alphanumeric).take(PRE_LEN).enumerate() {
   |                           ^^^^^^^^^^^ method cannot be called on `OsRng` due to unsatisfied trait bounds
   |
  ::: /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand_core-0.9.3/src/os.rs:47:1
   |
47 | pub struct OsRng;
   | ---------------- doesn't satisfy `OsRng: RngCore` or `OsRng: Rng`
   |
   = note: the following trait bounds were not satisfied:
           `OsRng: RngCore`
           which is required by `OsRng: Rng`
           `&OsRng: RngCore`
           which is required by `&OsRng: Rng`
           `&mut OsRng: RngCore`
           which is required by `&mut OsRng: Rng`

   Compiling icu_locid v1.5.0
Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `nuid` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...```

Then follows a couple of hours updating dependencies and such that does not make anything better.

This scenario has now happened to me four or five times when getting back to code I have not touched for some months. Not what I expect given my Cargo.toml and Cargo.lock have not changed. All that has changed is that I have a recent compiler.

What am I doing wrong?

2 Likes
2

did you forget to check in the cargo lock file to git?

1 Like
3

No. Cargo.toml and Cargo.lock are in my repo.

4

Dependency management. You should always use specific versions of your dependencies.

5

I think I am pretty specific about versions:

cat Cargo.toml
[package]
name = "conq_itc_link"
version = "0.1.0"
authors = ["zicog <zicog@example.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[[bin]]
name = "telnet_test"

[dependencies]
ring = "0.16.20"
ssh2 = "0.9.4"
nats = "0.24.0"
log = "0.4"
env_logger = "0.7.1"
clap = "2.33.3"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0.40"
anyhow = "1.0.32"
thiserror = "1.0"
telnet = {version = "0.2.1", features = ["zcstream"]}

What more can I do?

6

So the original issue was the time crate inference break in 1.80.0 as it said in the error message. It tells you to run cargo update which is probably a bad message as that (i believe) pulls in major upgrades. (edit: i believed wrong)
And now you have new library versions your code wasn't written against.
I would suggest you use your old cargo.toml and try to only update time and otherwise leave everything as it is.

1 Like
7

No, it does not pull in major version upgrades.

2 Likes
8

Where does time and rand come from?

9

oh sorry about that. then i guess some dependency had a breaking change without marking it as such? otherwise i don't know how you would get those trait bound errors from running cargo update.

10

The problem with nuid is their fault. They specified a dependency on the rand crate as >=0.8. When your Cargo.lock was generated, rand 0.9 did not exist, and nuid was compiled with rand 0.8, as it expected.

cargo update reruns the resolver. Now rand = ">=0.8" resolves to rand version 0.9, which has breaking changes[1] (as would be expected from a major version bump). nuid is now compiled with rand 0.9, which causes it to not compile at all.

The simple solution is to just update time in your Cargo.lock by using cargo update time.

  1. The changes that are relevant to this scenario are that OsRng no longer implements RngCore. It implements TryRngCore, since getting random data from the OS is fallible. ↩︎

21 Likes
11

No idea.

Turns out that cargo update as suggested in the error messages makes things worse. But cargo update time works!

5 Likes
12

Yep, I just did that before you posted. Thanks.

13

@cod10129 describes the actual problem accurately; it’s not really cargo’s fault that things get worse[1]. This problem could only be fixed either by nuid maintainers releasing point releases for 0.3.* (and probably also 0.4.*) that fix the incorrect rand dependency specifications, or by the crate bringing in this dependency (nats) updating their dependency to nuid version 0.5 [unless that’s a public dependency], which is unlikely judging by the maintenance message suggesting transition to async-nats which does depend on the nuid version 0.5 but has a different API presumably (at least in that it involves async fn) :man_shrugging:

  1. though the rustc error could probably consider mentioning commands such as cargo update time directly. Maybe something like cargo update time@0.3 works, too, but ensures even more minimal changes? [I’m not 100% sure if cutting off the version here is supported or if you need the exact time@0.3.…something… here] ↩︎

3 Likes
14

This is all very disturbing and I don't understand because:

  1. I have a Cargo.toml file that pins down the dependency versions I want.

  2. I have a Cargo.lock file that pins down every byte of code of every dependency with hashes and such.

  3. I have a compiler that I'm told can handle changes via its "editions" as specified in Cargo.toml.

And yet things break on me all the time.

What else do I have to lock down? The compiler? My OS?....

7 Likes
15

This is even more disturbing:

I went through and updated all the dependencies in my Cargo.toml except for clap as that breaks if I do so. I got a clean build:

$ cargo clean 
     Removed 2041 files, 434.2MiB total
$ cargo build
   Compiling ...
    ...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 13.20s

Then just for fun I deleted my Cargo.lock file and tried to rebuild:

$ rm Cargo.lock
$ cargo build
    Updating crates.io index
     Locking 196 packages to latest Rust 1.87.0-nightly compatible versions
      Adding clap v2.34.0 (available: v4.5.31)
   Compiling ...
   ...

   Compiling nuid v0.3.2
error[E0432]: unresolved import `rand::distributions`
  --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nuid-0.3.2/src/lib.rs:19:11
   |
19 | use rand::distributions::Alphanumeric;
   |           ^^^^^^^^^^^^^ could not find `distributions` in `rand`

error[E0599]: the method `sample_iter` exists for struct `OsRng`, but its trait bounds were not satisfied
  --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/nuid-0.3.2/src/lib.rs:82:27
   |
82 |         for (i, n) in rng.sample_iter(&Alphanumeric).take(PRE_LEN).enumerate() {
   |                           ^^^^^^^^^^^ method cannot be called on `OsRng` due to unsatisfied trait bounds
   |
  ::: /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand_core-0.9.3/src/os.rs:47:1
   |
47 | pub struct OsRng;
   | ---------------- doesn't satisfy `OsRng: RngCore` or `OsRng: Rng`
   |
   = note: the following trait bounds were not satisfied:
           `OsRng: RngCore`
           which is required by `OsRng: Rng`
           `&OsRng: RngCore`
           which is required by `&OsRng: Rng`
           `&mut OsRng: RngCore`
           which is required by `&mut OsRng: Rng`

Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `nuid` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Which brings us back to that pesky nuid problem. Grrr..

16

See maybe also Type inference breakage in 1.80 has not been handled well - policy - Rust Internals & Brainstorming: how to help old code locked to old `time` build on new toolchains - Rust Internals for how the time breakage happened. I don't know if there was some kind of policy change as a result of this, but there were definetly a lot of ideas on how to handle this better in the future.

10 Likes
17

Oh boy.... So it's hopeless.

There is a reason I see companies running ancient PC's with Windows XP and some prehistoric IDE and compiler installed that is the only way they can maintain their embedded systems software and other things.

I guess this problem is not going to be fixed in my lifetime.

Anyway, all is working just now, so onward and upward! Thanks all.

2 Likes
18

There's a lint in the works to avoid that specific case from happening again.

19

It should also be mentioned you can fairly easily pin the compiler version for a project, too:

Generally not needed, but it's especially handy for using unstable features with nightly versions, and it works for cases like here where there's an actual breaking change on compiler update (which should be very rare!)

3 Likes
20

I am to blame for the diagnostic telling you to do cargo update instead of cargo update time. That was an oversight of mine (and the reviewers) in the scramble to get something in place quickly.

That should not be the case and if it is then absolutely file tickets or open threads here. That's not how things are meant to be.

Oh, boy. That's quite the time bomb. It seems like they fixed it back in 2023 and then released 0.5 which included that, but that's two major releases after what OP had.

There's clippy::useless_conversion that you could use today, but it has false positives when it comes to type aliases. @josh gave me an idea on a way to implement accurate handling for that case and I'll try to implement it shortly.

Seeing this thread made the hairs in the back of my head stand up. We have a "time bomb" assertion in the codebase to remind us to remove the special note from 1.89, under the assumption that by that time the time issue would no longer be as prevalent in causing trouble to people (and that an alternative more generic solution would have been implemented in cargo by then), and this makes me think we might want to push that back a bit further in time (which is a discussion I am not eager to have to have).

24 Likes