bit-set 0.2.0's Cargo.toml no longer accepted

[m-ou-se]

Problem

When using bit-set = "0.2.0" as a dependency, it now fails with:

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

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `.cargo/registry/src/github.com-1ecc6299db9ec823/bit-set-0.2.0/Cargo.toml`

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

Steps
cargo new abc; cd abc; echo 'bit-set = "0.2.0"' >> Cargo.toml; cargo c

Possible Solution(s)
This seems to be caused by #9686

The Cargo.toml contains an empty [dependencies.bit-vec] block: https://docs.rs/crate/bit-set/0.2.0/source/Cargo.toml

The solution might very well be 'won't fix'. But users of that crate wouldn't have seen any warning about it before. (E.g. users of libusb that uses it indirectly, since the latest version still uses bit-set 0.2.0.)

Notes

It works fine on:

• cargo 1.55.0-nightly (3ebb5f1 2021-07-02)

It fails on:

• 1.55.0-nightly (66a6737 2021-07-14)

[alexcrichton]

Is there a sense for whether this is a super-prevelant error or not? This was known to probably break something, but the warning that "this will break in the future" was there for ~6 years so we figured nothing critical or big relied on it any more.

[m-ou-se]

That warning wasn't visible when depending on a crate with that problem, only when working on the crate itself. But yeah, six years is a long time. For me, my issue is already fixed by switching from libusb to rusb. Maybe it's good to keep this issue open for a while and see if others also run into this problem, and otherwise just close it.

[ehuss]

I did a full scan of crates.io to find how common it was and came up with this list of root offenders:

bit-set-0.1.0
bit-set-0.2.0
bit-set-0.3.0
confusion-0.0.1
cryptosphere-0.0.0
font-atlas-0.1.0
font-atlas-0.1.1
font-atlas-0.1.2
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.0
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-0.1.1
kinetic-rust-0.0.13
kinetic-rust-0.0.13
kinetic-rust-0.0.13
kinetic-rust-0.0.16
kinetic-rust-0.0.16
kinetic-rust-0.0.16
kinetic-rust-0.0.16
kinetic-rust-0.0.16
macaroons-0.1.0
macaroons-0.1.0
macaroons-0.1.1
macaroons-0.1.1
macaroons-0.2.0
macaroons-0.2.0
macaroons-0.2.1
macaroons-0.2.1
macaroons-0.2.1
openssl-0.0.2
openssl-0.0.2
openssl-0.0.2
openssl-0.0.2
openssl-0.1.0
openssl-0.1.0
openssl-0.1.0
openssl-0.1.0
openssl-0.1.1
openssl-0.1.1
openssl-0.1.1
openssl-0.1.1
petgraph-0.1.0
petgraph-0.1.1
petgraph-0.1.10
petgraph-0.1.11
petgraph-0.1.12
petgraph-0.1.13
petgraph-0.1.2
petgraph-0.1.3
petgraph-0.1.4
petgraph-0.1.5
petgraph-0.1.6
petgraph-0.1.7
petgraph-0.1.8
petgraph-0.1.9
pistoncore-sdl2_window-0.0.6
ptrace-0.0.1
ptrace-0.0.2
shell-0.2.0
shell-0.2.0
shell-0.3.0
shell-0.3.0
traverse-0.0.10
traverse-0.0.11
traverse-0.0.12
traverse-0.0.8
traverse-0.0.9
water-0.10.26-alpha
water-0.11.27-alpha
water-0.12.30-alpha
water-0.13.31-alpha
water-0.14.38-alpha
water-0.14.39-alpha
water-0.14.41-alpha
water-0.15.42-alpha
water-0.16.43-alpha
water-0.16.44-alpha
water-0.16.45-alpha

I'm not sure how common any of these are as dependencies, but I think that list is small enough that this likely is "wontfix".

[alexcrichton]

Hm well it's definitely a bug that we didn't, at some point, turn the warnings on for deps-of-deps. That's something we should be vigilant for in the future!

In any case I agree that leaving this here for a bit to see if others run into it is a good idea. If the impact is larger than expected we can always revert, implement a better warning, and then re-land the error in a year or so.

[ikravets]

I've just run into exactly the same issue described by @m-ou-se. I'm using the latest libusb crate, which depends on bit-set v0.2.0. Rolling back to nightly-2021-07-02 as a workaround for now.

[m-ou-se]

(@ikravets Note that the libusb crate hasn't been updated in five years. The rusb crate seems to be a maintained fork of it, with an almost identical public interface, and does not depend on bit-set 0.2.0.)

This is a super frustrating regression that could come and bite anybody at any time and is a breaking change for existing versions of existing crates. As consumers of large dependency trees, please can we get a way to turn this error off?

[ehuss]

Sorry for the trouble, we did not expect anyone to be using these dependencies. I have opened #9911 and #9912 to revert this. If we try again in the future, we will likely try to use the future-incompatible warning system which can report potential breaking in dependencies ahead of time.