Deriving uniffi::Error on enum with variant with unnamed fields produces confusing errors

[cowlicks]

The code:

#[derive(uniffi::Error)]
pub enum Foo {
    Bar(String),
}

Produces the following error:

$ cargo check

Checking ...
 error: expected expression, found `,`
 --> src/error.rs:1:10
  |
1 | #[derive(uniffi::Error)]
  |          ^^^^^^^^^^^^^ expected expression
  |
  = note: this error originates in the derive macro `uniffi::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

error: expected identifier, found `:`
 --> src/error.rs:1:10
  |
1 | #[derive(uniffi::Error)]
  |          ^^^^^^^^^^^^^
  |          |
  |          expected identifier
  |          while parsing this struct
  |
  = note: this error originates in the derive macro `uniffi::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

error: proc-macro derive produced unparsable tokens
 --> src/error.rs:1:10
  |
1 | #[derive(uniffi::Error)]
  |          ^^^^^^^^^^^^^

error: UniFFI only supports enum variants with named fields (or no fields at all)
 --> src/error.rs:3:5
  |
3 |     Bar(String),
  |     ^^^^^^^^^^^

error[E0769]: tuple variant `Self::Bar` written as struct variant
 --> src/error.rs:1:10
  |
1 | #[derive(uniffi::Error)]
  |          ^^^^^^^^^^^^^
  |
  = note: this error originates in the derive macro `uniffi::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0063]: missing field `0` in initializer of `Foo`
 --> src/error.rs:1:10
  |
1 | #[derive(uniffi::Error)]
  |          ^^^^^^^^^^^^^ missing `0`
  |
  = note: this error originates in the derive macro `uniffi::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0063, E0769.
For more information about an error, try `rustc --explain E0063`.
error: could not compile `hyperbee` (lib) due to 6 previous errors

This looks a lot like a syntax error. It left me confused for a while. The solution I found was to use #[uniffi(flat_error)] on the enum. This should probably recommended by the error.

[mgeisler]

I'm just another user of the library, but I got the same error. It confused me too 😄

Using flat_error is one option as you write, as it naming the fields. This is hinted at in The uniffi::Enum derive, which says

Any fields inside variants must be named.

It would be ideal if the compilation error could mention this directly.

[mhammond]

I very recently landed 442f2e4 - I don't think that actually works for error types, but I plan to come back to it and make sure it does - which would possibly side-step this problem. I also failed to update that part of the enum docs.

error handling in proc-macros is generally quite poor though - most of these errors aren't emitted by us, but by the compiler based on the (faulty) code we generate, so we'd need to do extra work to try and detect these cases just for error reporting sake, which is probably not going to be possible in some cases - but I agree we should do what we can.

[mhammond]

and with #2118 we can call this done :)