Build failure traced back to old commit

[terror]

When building bitvec from source, I'm getting a build error and after running git bisect I could trace it back down to this commit -> 47d6e19

Here is the message I'm receiving

error[E0034]: multiple applicable items in scope
  --> src/mem.rs:28:19
   |
28 |     const INDX: u8 = Self::BITS.trailing_zeros() as u8;
   |                      ^^^^^^^^^^ multiple `BITS` found

OS: macOS Big Sur 10.16 20C69 x86_64
cargo --version: cargo 1.36.0 (c4fcfb725 2019-05-15)

Note that I'm using Big Sur which may play a role in the cause of this error.

[EthanYidong]

Actually, this is due to a breaking change in funty ferrilab/funty@b87325b, which ads a BITS constant that bitvec is glob importing. Version 1.1.0 of funty works fine, so as a temporary workaround, add funty = "=1.1.0" to your Cargo.toml

[Zorotic]

Actually, this is due to a breaking change in funty myrrlyn/funty@b87325b, which ads a BITS constant that bitvec is glob importing. Version 1.1.0 of funty works fine, so as a temporary workaround, add funty = "=1.1.0" to your Cargo.toml

You are a live saver 💯

[iptq]

Maybe it would be a good idea to pin to minor versions of dependencies as well, since glob-imports are used in code?

[matthiasbeyer]

Maybe it would be a good idea to pin to minor versions of dependencies as well, since glob-imports are used in code?

I guess the proper way would not to use glob imports at all?

[iptq]

Wait, I looked into it a bit and it doesn't look like a glob import; the problem is in src/mem.rs, the BitMemory trait is declaring an associated member called BITS:

const BITS: u8 = mem::size_of::<Self>() as u8 * 8;

But IsNumber which is a super-super-super-trait of BitMemory (indirectly through IsUnsigned and IsInteger), has been updated in version 1.2 of funty to include a BITS member as well, implementing the same functionality:

const BITS: u32;

Looks like both crates seem to just be waiting on the stabilization of the ::BITS member in the standard library, but for now, the rust compiler can't disambiguate between the two, so it raises the error.

First off, this won't happen if versions are pinned to at least minor version, since the semver specification allows minor versions to introduce new functionality into the public API:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

This means that if you don't pin to minor versions, your dependencies could cause collisions like what just happened. Since this is a library and not a bin, it can't take advantage of a lockfile so it should ideally pin to versions as exact as possible.

As for the actual problem, ultimately the decision is up to the maintainers but I think it'll be OK to depend on the IsNumber implementation since it's the same so there's not a need to reimplement it if depending on funty >=1.2.

The complication there would be the differences in the API (u8 vs. u32), which would probably require a major version bump for bitvec, but it'll be a major version bump either way since the BITS can't remain if IsNumber remains a supertrait. (or just never bump funty versions again)

[gui1117]

can't we explicit usage of BITS in bitvec to avoid ambiguity ? #109

[gui1117]

the above fix is based on 0.20, I open a fix for 0.20.1 #110

[myrrlyn]

I completely forgot to check up on this after publishing the patch releases, which is 100% my bad.

Is everyone fixed now

[tarcieri]

@myrrlyn yep, thanks!