DEV Community

Mykhailo
Mykhailo

Posted on

Three cargo errors that don't happen any more

#rust #cargo #testing #writing

Three of the cargo errors I sat down to document don't happen any more. I only found out because the build refused to publish the pages.

The setup: I'm generating one page per diagnostic for a Rust learning site, and every page has to be confirmed by a real toolchain before it ships. For the cargo corpus that means an entry is a whole project, not a snippet. A build script writes the file map into a temp dir, runs actual cargo in it, and compares what came back against what the page claims. If the two disagree, the entry doesn't exist.

31 cargo entries survived. Here are the three that didn't, on cargo 1.96.0.

A manifest with no version 

[package]
name = "probe"
edition = "2021"
Enter fullscreen mode Exit fullscreen mode

I wrote this expecting a parse failure naming the missing package.version. What I got:

   Compiling probe v0.0.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.25s
Enter fullscreen mode Exit fullscreen mode

It builds. version is optional now and defaults to 0.0.0, which cargo prints right there in the compile line if you're reading it. The error still fires for a missing name, so the neighbouring entry in my corpus is fine:

error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`
Enter fullscreen mode Exit fullscreen mode

Name and version used to fail the same way. They don't now, and I'd have written that they do.

A misspelled key in [profile.release] 

[profile.release]
opt-levle = 3
Enter fullscreen mode Exit fullscreen mode 
warning: unused manifest key: profile.release.opt-levle
   Compiling probe v0.1.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
Enter fullscreen mode Exit fullscreen mode

A warning, and a build that succeeds with the default opt-level. This is the one I'm least happy about losing, because the failure mode is worse than an error would be. Your release build is not optimised the way you asked and the only evidence is one line that scrolls past. An error would at least stop you.

The typo case that does still error is a required key, and the message is worth looking at:

[package]
naem = "probe"
version = "0.1.0"
Enter fullscreen mode Exit fullscreen mode 
error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`
Enter fullscreen mode Exit fullscreen mode

Cargo tells you what's absent, not what you misspelled. naem is sitting right there on line 2 and never gets mentioned.

A virtual manifest with one member 

[workspace]
resolver = "2"
members = ["app"]
Enter fullscreen mode Exit fullscreen mode

cargo run in that root, I was told, refuses because the root defines no package. It doesn't:

   Compiling app v0.1.0 (/tmp/probe/app)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/app`
hello from app
Enter fullscreen mode Exit fullscreen mode

One member with a binary means one answer, so cargo picks it. Add a second member and the old error comes back, which is the version I kept:

error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: app, tool
Enter fullscreen mode Exit fullscreen mode

So the entry isn't wrong so much as it needed a workspace big enough to be ambiguous. That's a different page from the one I'd planned to write.

Why I'd have got all three wrong

I didn't reason my way to these. I lifted them from what I'd read, and what I'd read was written when they were true. I haven't gone back to count how many of those write-ups are still near the top of a search for the error text, so I'm not going to give you a number, but the phrasing is still out there in blog posts and answers and nothing about a stale answer looks stale.

Documentation of an error is a claim about behaviour at a point in time, and cargo keeps relaxing things. Each relaxation turns a correct old page into a confident wrong one. Nobody edits the old page, because nothing tells them to.

The gate is the whole value here. It's about 200 lines that shell out to cargo and diff two strings, and its only real job is telling me to delete something. Three pages I'd have sworn were correct, deleted before anyone read them, by a script with no opinions.

What I'm less sure about: I now have three documented non-errors and nowhere to put them. The page that says "this used to fail and doesn't" is probably more useful than the page that says "this fails", because it's the one that contradicts what you already read. But it isn't a diagnostic, and the site is organised entirely around diagnostics. I haven't worked out where it goes: https://codecrab.app/?r=devto-cargo-stale

Top comments (0)