Conflicting implementations of trait `Debug` for type `RunningStateBits`

[dominikwilkowski]

Hi there,

I'm getting an error when trying to compile:

λ cargo run
   Compiling sungrow-winets v0.1.0
error[E0119]: conflicting implementations of trait `Debug` for type `RunningStateBits`
   --> /Users/dominik/.cargo/registry/src/github.com-1ecc6299db9ec823/sungrow-winets-0.1.0/src/lib.rs:255:1
    |
255 | #[bitmask_enum::bitmask(u16)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `RunningStateBits`
256 | #[derive(Debug)]
    |          ----- first implementation here
    |
    = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0119`.
error: could not compile `sungrow-winets` due to previous error

Some system infos:

λ rustc -V
rustc 1.69.0 (84c898d65 2023-04-16)
λ arch
arm64
λ sw_vers
ProductName:        macOS
ProductVersion:     13.4
BuildVersion:       22F66

My Cargo.toml

[package]
name = "solar"
version = "0.1.0"
edition = "2021"

[dependencies]
sungrow-winets = "0.1.0"

And my main.rs

fn main() {
    println!("hello world");
}

[bjeanes]

Hey thanks for opening an issue!

I think I saw this last week myself after upgrading bitmask_enum. It seems to provide Debug itself. I think removing the derive may suffice, but I am checking locally now.

[bjeanes]

Ah I think I just need to release a new version of that crate. Can you try pulling in the crate as a git dependency and let me know if that works? If so, I'll release a bumped version.

[dominikwilkowski]

That seems to work.

This is my Cargo.toml now

[package]
name = "solar"
version = "0.1.0"
edition = "2021"

[dependencies]
sungrow-winets = { git = "https://github.com/bjeanes/modbus-mqtt.git" }
tokio = { version = "1.28.1", features = ["full"] }
tracing-subscriber = "0.3.17"

And main.rs

use std::time::Duration;

use sungrow_winets::*;

#[tokio::main]
async fn main() -> Result<(), Error> {
    tracing_subscriber::fmt::init();

    let host = std::env::args().nth(1).expect("must pass host/IP of WiNet-S as first argument");

    let client = Client::new(host).await?;

    let mut tick = tokio::time::interval(Duration::from_millis(200));
    loop {
        tick.tick().await;
        let data = client.running_state().await;
        println!("{:?}", &data);
    }
}

Note that I had to install tracing-subscriber as well which was included in the example without a note?

λ cargo run -- 10.0.0.101
   Compiling solar v0.1.0 (/Users/dominik/Sites/solar)
    Finished dev [unoptimized + debuginfo] target(s) in 0.80s
     Running `target/debug/solar 10.0.0.101`
Err(SungrowError { code: 301, message: Some("I18N_COMMON_READ_FAILED") })
Err(SungrowError { code: 301, message: Some("I18N_COMMON_READ_FAILED") })
^C

I'm getting a I18N_COMMON_READ_FAILED error now so no compile error anymore which means this issue is fixed with the code in the latest main branch. I take it that I18N_COMMON_READ_FAILED is common and a bit weird. Will dig into that later

[bjeanes]

I take it that I18N_COMMON_READ_FAILED is common and a bit weird.

Precisely. Sungrow's errors are a bit impenetrable tbh...

Note that I had to install tracing-subscriber as well which was included in the example without a note?

Interesting. This is my first time using tracing and it's been a fair few months so I wrote this. I'm not sure if that's expected or not. Is it a compile error without it or just an absence of log output?

I think some dependency issues might be subtly masked by me using a Cargo workspace. I might split this crate out into its own repo when I next work on the parent project.

so no compile error anymore which means this issue is fixed with the code in the latest main branch.

Yeah this is the commit from when I fixed it myself a month or so: https://github.com/bjeanes/modbus-mqtt/commit/4348e68543ed4d51d14de37a422f2ee02955f02d. I was compiling the whole workspace and doing crate updates so I didn't realise this was actually broken in 0.1.0. I don't think this was an issue when I released it, so I think one of the dependencies might have added the Debug in a patch release, which cause unintentional breakage.

Once I remember how I set up my release and tagging process, I'll release a 0.1.1 or something!

[bjeanes]

@dominikwilkowski I have released 0.2.0 of sungrow-winets and tokio_modbus-winets. Let me know if the former works from crates.io and if there is any issue I can yank and correct it. If all is well, feel free to close the issue :)

[dominikwilkowski]

Love your work! Thank you.

Interesting. This is my first time using tracing and it's been a fair few months so I wrote this. I'm not sure if that's expected or not. Is it a compile error without it or just an absence of log output?

Compiler error:

error[E0433]: failed to resolve: use of undeclared crate or module `tracing_subscriber`
 --> src/main.rs:7:2
  |
7 |     tracing_subscriber::fmt::init();
  |     ^^^^^^^^^^^^^^^^^^ use of undeclared crate or module `tracing_subscriber`

I would just not have it in the example code to keep it simple?

With 0.2.0 it all works. Thanks heaps

[bjeanes]

I would just not have it in the example code to keep it simple?

Thanks for clarifying. I need to review if you can have example-specific dependencies (or whether it needs to be a dev dependency or something) but if there is no such option, then removing it makes sense. I'll think about that!