bit-set 0.2.0 compilation failed

[positiveway]

Problem

#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

[heisen-li]

@rustbot label +A-crate-dependencies

[heisen-li]

It seems that in the 2024 edition the plan became wrong：
issue:#13629
Recent Changes:https://github.com/rust-lang/cargo/pull/13775/files#diff-3d8669050f6f1c07884ef5a4e9d344a98c7270f73f4683125a00e8a3cc6381e6

[epage]

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

• Updated bit-set crate to version 0.4 dcuddeback/libusb-rs#15
• Fix cargo error in bit-set crate by implementing own minimal BitSet dcuddeback/libusb-rs#45

[epage]

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

[tanriol]

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.