Not being able to use a cfg attribute on an interface method

[zeenix]

In GitLab by @brkp on Mar 24, 2023, 15:34

Hello there! I can not get the following snippet of code to compile:

struct Greeter {
    count: u64,
}

#[dbus_interface(name = "org.zbus.MyGreeter1")]
impl Greeter {
    #[cfg(target_arch = "aarch64")]
    fn function(&self) {}

    fn say_hello(&mut self, name: &str) -> String {
        self.count += 1;
        format!("Hello {}! I have been called {} times.", name, self.count)
    }
}

cargo build
   Compiling test v0.1.0 (/home/null/workspace/test)
error[E0599]: no method named `function` found for reference `&'call Greeter` in the current scope
  --> src/main.rs:11:8
   |
11 |     fn function(&self) {}
   |        ^^^^^^^^ method not found in `&'call Greeter`

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

Does this mean that having cfg attributes for conditional compilation is not supported? While I acknowledge that it is preferable for the D-Bus interface you receive to be consistently stable, I would appreciate having the option.

Thanks for this amazing set of libraries!

[zeenix]

Does this mean that having cfg attributes for conditional compilation is not supported?

Yes, seems like it.

While I acknowledge that it is preferable for the D-Bus interface you receive to be consistently stable, I would appreciate having the option.

As you recognized yourself, this is a very strange use-case. However, if you can contribute the changes and the changes are not too intrusive, I won't be against adding the support.

I'd strongly advice against doing this though. If you've methods that are really platform specific, I'd suggest splitting the interfaces/objects and have the whole dbus_interface type under the cfg. This way things are much clearer to the everyone.

Each time I encountered such "maybe" methods/properties as a user, I've found it very confusing and each time it wasted my time because it's very unexpected. D-Bus allows you to have as many interfaces on an object path as you like and they can be dynamically added/removed even so there is very rarely a good reason to do this.

But of course all that is very general and I've no idea about your specific use case. Maybe you've a good reason for needing this still. :shrug:

[zeenix]

Thanks for this amazing set of libraries!

You're welcome! :)

[zeenix]

In GitLab by @brkp on Mar 25, 2023, 18:56

Thanks for the lengthy response, I really appreciate it! I no longer need this feature since I decided I'd just keep the interface consistent and handle it in some other way.