🥅 zm: Handle non-String fields in error variant matching #1619

Hendrik-Hamerlinck · 2025-12-17T10:36:42Z

This PR updates the DBusError derive macro to support enum variants where the first field is not a String.
Previously, such cases resulted in an error when using custom errors. Now, the macro attempts to parse the first field as a String. If parsing fails, it returns None instead.

Example

#[derive(Debug, DBusError)]
pub enum ExampleDBusError {
   UnitVariant,
   UnnamedVariant(u32, String),
   UnnamedVariantString(String),
   NamedVariant { code: u32, message: String },
   NamedVariantString { message: String },
}

This now compiles and expands the description as following

fn description(&self) -> Option<&str> {
    match self {
        Self::UnitVariant => None,
        Self::UnnamedVariant(..) => None,
        Self::UnnamedVariantString(desc, ..) => Some(desc),
        Self::NamedVariant { .. } => None,
        Self::NamedVariantString { message } => Some(message),
    }
}

Return None when the first field of a DBusError variant is not a String. This allows custom error variants with non-String or no fields to work, addressing a FIXME in the macro implementation.

zeenix · 2025-12-17T12:57:30Z

@Hendrik-Hamerlinck Thanks so much for this contribution. 👍 I'll have a look at it soon but let me start with a nitpick about commit emoji. 😆 This is not a bug fix since I don't think we have advertised anywhere that this already works, nor it has every worked AFAIK.

Also I have to ask, how come you ended up using the emoji code rather than the emoji character? You are far from the first one to make this mistake so this is not on you but more like me failing in communicating this in the contribution guide. I'm only asking so I can try to make this clearer.

You can also pick an emoji direcitly from here (please remember to copy the emoji itself and not the :emoji-code: string, by just clicking on it). NOTE: This is a curated list of emojis that have specific meanings. Please use one of the methods recommended here to select/fetch the most appropriate one. 🙏

zeenix · 2025-12-17T12:58:59Z

I took the liberty of adding the most appropriate emoji to the PR title (please copy&paste that on the commit title).

zeenix

LGTM in general. Thanks again for this contribution. Apart from the nitpicks (sorry, I'm a perfectionist 😭), we need to also update the macro docs (in lib.rs) and need a test case (perhaps just updating the example in the docs is sufficient).

zeenix · 2025-12-17T13:02:44Z

zbus_macros/src/error.rs

                Self::#ident => None,
            },
-            Fields::Unnamed(_) => {
+            Fields::Unnamed(fields) => (|| {


Why switch to anonymous functions, just to call them immediately? This makes this change more intrusive than it would otherwise need to be and it's best to keep changes as small as possible.

Yeah I was not entirely happy about it. In my own version where we use rust 2024 I did something like this:

Fields::Named(n) => { if let Some(first_field) = n.named.first() && let Type::Path(type_path) = &first_field.ty && type_path.path.is_ident("String") { let f = &first_field.ident; quote! { Self::#ident { #f, } => Some(#f), } } else { quote! { Self::#ident { .. } => None, } } }

But the project is on 2021 and you cannot chain let pattern matching. So to prevent having to return the same value in each else branch I switched to an inline function, so that I could return directly. Perhaps there are better ways to do it?

To avoid nesting, I tend to use multiple if let .. else statements in a row combined with early return/break (in the else blocks). I think you can use that here.

2024 edition was stabilized in 1.85, which is almost a year old now so I'd be happy to bump the MSRV and switch to that edition. However, that should happen in a separate PR, if you'd like to contribute that as well.

Great, that would simplify this change. While updating the tests I noticed that my change only works under the 2024 edition. I'll send a PR for bumping the MSRV.

codspeed-hq · 2025-12-17T13:10:51Z

CodSpeed Performance Report

Merging #1619 will not alter performance

_{Comparing barcoopensource:fix/error-variant-non-strings (013e003) with main (7e447ac)}

Summary

✅ 22 untouched

Hendrik-Hamerlinck · 2025-12-17T13:37:57Z

@Hendrik-Hamerlinck Thanks so much for this contribution. 👍 I'll have a look at it soon but let me start with a nitpick about commit emoji. 😆 This is not a bug fix since I don't think we have advertised anywhere that this already works, nor it has every worked AFAIK.

Also I have to ask, how come you ended up using the emoji code rather than the emoji character? You are far from the first one to make this mistake so this is not on you but more like me failing in communicating this in the contribution guide. I'm only asking so I can try to make this clearer.

You can also pick an emoji direcitly from here (please remember to copy the emoji itself and not the :emoji-code: string, by just clicking on it). NOTE: This is a curated list of emojis that have specific meanings. Please use one of the methods recommended here to select/fetch the most appropriate one. 🙏

Thanks for the quick review.

Missing on the emoji is on me, I just noticed I didn't read the entire emoji part through. After clicking on the first link I assumed you just needed to copy the code. I will edit it as requested.

zeenix · 2026-01-09T17:21:26Z

@Hendrik-Hamerlinck Hi, could you please rebase this branch?

🐛 zm: Handle non-String fields in error variant matching

013e003

Return None when the first field of a DBusError variant is not a String. This allows custom error variants with non-String or no fields to work, addressing a FIXME in the macro implementation.

zeenix changed the title ~~🐛 zm: Handle non-String fields in error variant matching~~ 🥅 zm: Handle non-String fields in error variant matching Dec 17, 2025

zeenix requested changes Dec 17, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

🥅 zm: Handle non-String fields in error variant matching #1619

🥅 zm: Handle non-String fields in error variant matching #1619

Uh oh!

Hendrik-Hamerlinck commented Dec 17, 2025

Uh oh!

zeenix commented Dec 17, 2025

Uh oh!

zeenix commented Dec 17, 2025

Uh oh!

zeenix left a comment

Uh oh!

zeenix Dec 17, 2025

Uh oh!

Hendrik-Hamerlinck Dec 17, 2025 •

edited

Loading

Uh oh!

zeenix Dec 17, 2025 •

edited

Loading

Uh oh!

Hendrik-Hamerlinck Dec 17, 2025

Uh oh!

codspeed-hq bot commented Dec 17, 2025

Uh oh!

Hendrik-Hamerlinck commented Dec 17, 2025

Uh oh!

zeenix commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

🥅 zm: Handle non-String fields in error variant matching #1619

Are you sure you want to change the base?

🥅 zm: Handle non-String fields in error variant matching #1619

Uh oh!

Conversation

Hendrik-Hamerlinck commented Dec 17, 2025

Example

Uh oh!

zeenix commented Dec 17, 2025

Uh oh!

zeenix commented Dec 17, 2025

Uh oh!

zeenix left a comment

Choose a reason for hiding this comment

Uh oh!

zeenix Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Hendrik-Hamerlinck Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zeenix Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hendrik-Hamerlinck Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

codspeed-hq bot commented Dec 17, 2025

CodSpeed Performance Report

Merging #1619 will not alter performance

Summary

Uh oh!

Hendrik-Hamerlinck commented Dec 17, 2025

Uh oh!

zeenix commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Hendrik-Hamerlinck Dec 17, 2025 •

edited

Loading

zeenix Dec 17, 2025 •

edited

Loading