conflicting implementation in crate embedded_hal

[little-arhat]

Hello,

I updated nightly and got this error trying to compile some code:

rustc 1.46.0-nightly (2753fab7c 2020-07-05)

417:"checksum embedded-hal 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)" = "fa998ce59ec9765d15216393af37a58961ddcefb14c753b4816ba2191d865fcb"

error[E0119]: conflicting implementations of trait `embedded_hal::digital::v2::toggleable::Default` for type `gpio::PF10<_, gpio::Output<_, _>>`:
   --> /Users/r/.cargo/registry/src/github.com-1ecc6299db9ec823/alt-stm32f30x-hal-0.22.1/src/gpio.rs:515:13
    |
515 | /             impl<PT: PullType, OT:OutputType, OS:OutputSpeed> v2::toggleable::Default
516 | |                 for $PXi<PT, Output<OT, OS>> {}
    | |_______________________________________________^
...
648 | / gpio!(GPIOF, Gpiof, gpiof, iopfen, iopfrst, F, PFx, [
649 | |     PF0: (pf0, 0, afrl),
650 | |     PF1: (pf1, 1, afrl),
651 | |     PF2: (pf2, 2, afrl),
...   |
655 | |     PF10: (pf10, 10, afrh),
656 | | ]);
    | |___- in this macro invocation
    |
    = note: conflicting implementation in crate `embedded_hal`:
            - impl<T> embedded_hal::digital::v2::toggleable::Default for T
              where T: embedded_hal::digital::v1::toggleable::Default;
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Is this regression in compiler/embedded-hal or is it expected change and implementors (alt-stm32f30x-hal in this case) should fix their libraries?

Thanks!

[ryankurte]

uhoh, that shouldn't happen. the related line is here. we provide a polyfill from v1 to v2 types for forward compatibility (though this is all going away, and changing, in the upcoming v1.0.0 release #177)

it looks like your hal is trying to implement both the original and v2 traits where only one should be implemented?
(also as an aside i believe all the stm32fNNx device crates have been deprecated in favour of stm32fNxx family crates, whether or not this impacts your fork).

do be aware that we're preparing for a big-ol breaking change to resolve some, inconsistencies, in embedded-hal, so depending on your stability requirements you may wish to fix the duplicate hal definitions or to update to the alpha release, which does introduce some changes

[little-arhat]

@ryankurte Thanks, indeed this was the problem. Wonder why this worked before and what was changed in Rust.

As for stm32fNNx vs stm32fNxx, alt-stm32f30x-hal depends on stm32f3 so users are free to choose device using cargo features.

[ryankurte]

We fixed a couple of things on the polyfils in 0.2.4, (#220) which is probably what brought this to light.

[Dirbaio]

This is fixed in 1.0, thanks to it not having any "compat" stuff.