bdf regress because bit-set 0.3.0 disappeared in the recent few months

[tommythorn]

Current Behavior

I depend on the bdf crate and it worked fine a new months ago (at least as recent as June 4th). Alas, it fails now due to...

error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Expected Behavior

It should work

Steps To Reproduce

I can also reproduce this with

$ cargo new brokeness;cd brokeness;cargo add [email protected];cargo check
    Creating binary (application) `brokeness` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
    Updating crates.io index
      Adding bit-set v0.3.0 to dependencies
             Features:
             - nightly
    Updating crates.io index
     Locking 3 packages to latest compatible versions
      Adding bit-set v0.3.0 (latest: v0.8.0)
error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Environment

This happens on all platforms

• Browser:
• OS:

Anything else?

Aren't crates supposed to be immutable for life?

[tommythorn]

Yumechi-san kindly helped: "Crates were immutable but toolchains were not, so some dependency definitions become invalid when you update.

The error I see on your package says bit-set has a Cargo.toml which depends on bit-vec but has absolutely no version specifier (not even a '*'), that is probably what is broken, I would still fork bdf and update the bit-set dependency."

I guess I didn't know this could happen (which seems quite bad).

Feel free to close this if there is nothing more to add.

[epage]

The change in question is rust-lang/cargo#13775 which we further talked about in rust-lang/cargo#13824.

My main concern is with the error message reported in the issue. When I run this, Cargo gives some more detail than mentioned in the issue.

$ cargo check -V
cargo 1.81.0 (2dbb1af80 2024-08-20)
$ cargo add bdf
    Updating crates.io index
      Adding bdf v0.6.0 to dependencies
    Updating crates.io index
     Locking 10 packages to latest compatible versions
      Adding bit-set v0.3.0 (latest: v0.8.0)

$ cargo check
  Downloaded thiserror-impl v1.0.64
  Downloaded thiserror v1.0.64
  Downloaded syn v2.0.79
  Downloaded bit-set v0.3.0
error: failed to parse manifest at `/home/epage/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bit-set-0.3.0/Car
go.toml`

Caused by:
  dependency (bit-vec) specified without providing a local path, Git repository, version, or workspace dependency to u
se

$ cargo +nightly -V
cargo 1.83.0-nightly (eaee77dc1 2024-09-19)

$ cargo +nightly add bdf
    Updating crates.io index
      Adding bdf v0.6.0 to dependencies
    Updating crates.io index
     Locking 9 packages to latest compatible versions
      Adding bit-set v0.3.0 (available: v0.8.0)

$ cargo +nightly check
error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/home/epage/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bit-set-0.3.0/Cargo.to
ml`

Caused by:
  dependency (bit-vec) specified without providing a local path, Git repository, version, or workspace dependency to u
se

It says what manifest failed and why. While cargo tree -i bit-set does no work, you can browse crates.io for what depends on bit-set.

As we rework some of Cargo's error reporting, this does want me to make sure we do as much error recovery as possible and allow cargo tree to still report a tree on error.

I do find it strange that nightly added "failed to download" and "unable to get packages from source". 1.82 also has that message. After further investigation, it turns out it is not associated with the version but if the package was already downloaded. My message changed on 1.81 and doing rm -rf ~/.cargo/registry brought it back again. We have some gaps in our adding of error context (and our error context is a bit inaccurate in this case).

[Turbo87]

@rustbot transfer cargo

[rustbot]

Error: This repository is not enabled to use triagebot. Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[tommythorn]

Thanks Ed. FWIW, as a still green ruster, none of the error messages above are clear to me. Like it was not at all obvious that this happened because I upgraded my tools.

[epage]

Yes, identifying a problem is in a change in a tool is a harder problem to call out.

[Turbo87]

let's try this again:

@rustbot transfer cargo

[epage]

For me, the question at this time is what, if anything, we should do for this case.

As shown in my post, the error message at least calls out that bit-set can't be parsed and why. As this is a hard error, this is unlikely to spread to new cases

Options

• Do nothing and this will fade away
• We put in a hack specifically for bit-set to provide a clearer message for that one case
• Implement a form of error recovery so at least cargo tree can run to see how this happened
  • e.g. I've talked about moving most parse error reporting into the lint analyze phase.