Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another IORPCMessage debug trait issue #12

Open
segevfiner opened this issue Feb 25, 2023 · 5 comments
Open

Another IORPCMessage debug trait issue #12

segevfiner opened this issue Feb 25, 2023 · 5 comments

Comments

@segevfiner
Copy link

See https://github.com/segevfiner/keepawake-rs/actions/runs/4272014787/jobs/7436882628

 error[E0119]: conflicting implementations of trait `Debug` for type `IORPCMessage`
     --> /Users/runner/work/keepawake-rs/keepawake-rs/target/aarch64-apple-darwin/release/build/apple-sys-7a498b7b0123b7f9/out/IOKit.rs:55036:10
      |
55036 | #[derive(Debug)]
      |          ^^^^^ conflicting implementation for `IORPCMessage`
...
82951 | impl ::std::fmt::Debug for IORPCMessage {
      | --------------------------------------- first implementation here
      |
      = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)
@segevfiner
Copy link
Author

segevfiner commented Feb 26, 2023

Bumping to macos-12 seems to have fixed it. Guess the issue is with macos-11. Obviously we don't want a fix to break macos-12+ support if macos-11 support is something you care about.

@youknowone
Copy link
Owner

apple-sys is very dependent on macOS SDK versions by design unless #10 be completed.

@youknowone
Copy link
Owner

youknowone commented Feb 27, 2023

probably adding derive check around here will be possible https://github.com/youknowone/apple-sys/blob/main/bindgen/src/builder.rs#L108

@newbeeAirfeeen
Copy link

Regarding the above issue, I encountered the same situation on macos monterey 12 version. In the header file IORPC.h of the Apple System SDK, IORPCMessage is a struct. bindgen provides derive-debug for struct by default。
The following is your code snippet and part of bindgen cargo expand code snippet

  1. apple-sys/bindgen/builder.rs:47
    image
    2.cargo expand
BindgenOptions {
        rust_target,
        rust_features: (rust_target.into()),
        layout_tests: true,
        derive_copy: true,
        derive_debug: true,
        anon_fields_prefix: (DEFAULT_ANON_FIELDS_PREFIX.into()),
.....

What I don't understand is:
Why extra writing

        for ty in &self.config.impl_debugs {
            if out.contains(ty) {
                out.push_str(&format!(
                    r#"
                       impl ::std::fmt::Debug for {ty} {{
                          fn fmt(&self, f: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {{
                          f.debug_struct(stringify!(#ty)).finish()
                       }}
                 }}
                "#
                ));
            }
        }

Below is my modified version. As shown below:
image
Below is my modified version. Add as builder = builder in apple-sys/bindgen/builder.rs:65

             .derive_debug(true)
             .clang_args(&clang_args)
             .layout_tests(self.config.layout_tests)
             .rustfmt_bindings(true);

Make sure the value of derive_debug is true. Then comment out the extra code mentioned above and the related code in Bindgen.toml. Then I successfully built it. Do you think there is anything wrong with this? If it's okay with you, I can submit a PR. Thanks!

@Nadahar
Copy link

Nadahar commented Apr 4, 2024

I have the same problem when trying to build RustDesk on macOS 12, and to be honest I don't have a clue about what to do about it or what's causing it. I assume it's caused by incompatible versions of xcode, rust, macOS and whatnot, but is there any way for a non-rust-guru to figure out how to get past this?

The closest I've come to any understanding is that there's a macro defined that is already defined in ::std::fmt::Debug. I guess that this hasn't always been the case, or this would probably never have been defined here - but what decides if it's already defined in ::std::fmt::Debug? Does that depend on the Rust version itself, or on some other component on macOS that I can change the version of? Or did I just misunderstand this completely?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants