dbus2 / zbus-old

Rust D-Bus crate.
https://gitlab.freedesktop.org/dbus/zbus
Other
49 stars 13 forks source link

zvariant: Type will fail silently if using with serde skip_serializing #309

Closed zeenix closed 1 year ago

zeenix commented 1 year ago

In GitLab by @zhangyuannie on Dec 18, 2022, 08:03

See also https://serde.rs/field-attrs.html#skip_serializing

Ideally serde's features should work. Otherwise panicking could be very helpful to let the user know this feature is not supported with Type.

For skip_serializing and skip_serializing_if specifically, I believe this is due to serde not serializing the given field while Type produce a signature with the skipped field, which I don't see an easy way to fix.

skip_deserializing probably have similar issue.

zeenix commented 1 year ago

Doesn't #35 and #85 already cover this?

zeenix commented 1 year ago

Ideally serde's features should work. Otherwise panicking could be very helpful to let the user know this feature is not supported with Type.

If we could read Serialize macro's attributes from Type, we can just support serde's attributes and do the right thing. I don't think that's possible.

zeenix commented 1 year ago

In GitLab by @zhangyuannie on Dec 18, 2022, 23:55

35

I may have missed it but I didn't see this mentioned in the docs. :sweat_smile:

85

seems to be more about the TypeDict use case. I'm trying to ask for the Type macro to simply fail if it reached something unsupported, unlike right now where no warning is emitted.

If we could read Serialize macro's attributes from Type

My bad, I'm not too familiar with syn, I thought it is possible as proc macro works on tokens. In this case, feel free to close this issue. :smile:

If doable, it would be awesome if something could be happening to indicate something went wrong. Thanks for taking the time.

zeenix commented 1 year ago

35

I may have missed it but I didn't see this mentioned in the docs.

Oops, this was supposed to be #32.

If doable, it would be awesome if something could be happening to indicate something went wrong. Thanks for taking the time.

As I said, If it's doable, then we can do the right thing and hence there is no warning needed. Keep in mind that I've not actually checked. If it's not doable, then we can't do warning either.

zeenix commented 1 year ago

marked this issue as a duplicate of #32

zeenix commented 1 year ago

marked this issue as related to #32