num-traits icon indicating copy to clipboard operation
num-traits copied to clipboard

Unusual breaking change introduced in 0.2.6

Open Lymia opened this issue 7 years ago • 2 comments

The following code builds fine on 0.2.5, but fails to compile on 0.2.6. Extremely unusually, testing seems to indicate that was introduced in d2bf4e04e, a rustfmt commit.

extern crate num_traits;
use num_traits::*;

pub trait Trait {
    type Num: PrimInt + CheckedShl;
}
pub fn function<T: Trait>(b: usize) -> T::Num {
  T::Num::one() << b
}

Error encountered:

error[E0308]: mismatched types
 --> src/lib.rs:8:20
  |
8 |   T::Num::one() << b
  |                    ^ expected u32, found usize

Moving the associated type's bounds directly into the trait bounds for T, as well as removing the bound on CheckedShl both seem to clear this error.

Changing the body of function to Shl::<usize>::shl(T::Num::one(), b) also clears the error, proving that an implementation of Shl<usize> does exist for T::Repr.

This seems to be due a bug in rustc, where the order that traits are declared in influences their resolution in operators.

Lymia avatar Sep 17 '18 14:09 Lymia

Very strange!

For reference, I see that you also filed a rustc issue: https://github.com/rust-lang/rust/issues/54296

cuviper avatar Sep 17 '18 18:09 cuviper

Extremely unusually, testing seems to indicate that was introduced in d2bf4e0, a rustfmt commit.

In particular, rustfmt sorted the mod declarations, so now int comes before ops here: https://github.com/rust-num/num-traits/commit/d2bf4e04e43add49c4ab6b7df794501b09d0a081#diff-b4aea3e418ccdb71239b96952d9cddb6R53

If I just swap those two lines, your example works again.

Yet even that is fickle. I swapped the lines and got it to build, then swapped back and it still built! But cargo clean then build fails again, so I guess incremental compiling is interfering here too.

cuviper avatar Sep 18 '18 18:09 cuviper

Seems to have been long fixed upstream.

Lymia avatar Mar 21 '23 15:03 Lymia