cargo
cargo copied to clipboard
rust-lang
bit-set 0.2.0 compilation failed
Problem
https://github.com/rust-lang/cargo/issues/9885 Same issue reappeared with bit-set v.0.2.0 dependency of libusb on nightly 1.80.0 (maybe even on 1.79, it was ok last time I checked 2 weeks ago)
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
No response
It seems that in the 2024 edition the plan became wrong： issue:https://github.com/rust-lang/cargo/issues/13629 Recent Changes:https://github.com/rust-lang/cargo/pull/13775/files#diff-3d8669050f6f1c07884ef5a4e9d344a98c7270f73f4683125a00e8a3cc6381e6
This has had a "we'll break this in the future" message for 2.5 years (though not elevated for dependents to see). The last bit-set version with this problem was 0.3.0 and was released 8 years ago with the fix in 0.4.0 was also released 8 years ago. There have been 4 newer versions since then.
Of the 93 direct dependents, the following are the only ones where the latest version still depends on a "bad" version of bit-set:
- https://crates.io/crates/libusb
- https://crates.io/crates/bdf
- https://crates.io/crates/rustlex_codegen
- https://crates.io/crates/ilc-ops
- https://crates.io/crates/brinicle_voices
Looking at their recent download counts, they are fairly low, with the "most popular" hovering around 150/day
libusb has had two PRs for addressing this (directly or indirectly) since 2017 and 2021
- https://github.com/dcuddeback/libusb-rs/pull/15
- https://github.com/dcuddeback/libusb-rs/pull/45
We talked about this in today's meeting.
We are planning to keep this as-is because
- This was a bug
- We started notifying several years ago about this
- Newer versions of the package are fixed and this is a problem with an unmaintained dependent
- There seem to be maintained, more popular replacements in the form of rusb which had a release just 3 days ago and has 6x the total downloads
I want to note that the error message here is less useful than usual - it tells me about the problematic crate, but does not tell me how it got pulled in, and cargo tree -i bit-set just produces the same error again without any additional information, so I need to look in Cargo.lock manually.
