Incorrect tuple recognition with `derive_more::Unwrap`

[artslob]

I used most recent derive_move as dependency:

derive_more = "0.99.17"

Deriving Unwrap for this enum works as expected:

#[derive(derive_more::Unwrap)]
pub enum Q1 {
    A(i32),
    B(i32),
}

But this one fails:

#[derive(derive_more::Unwrap)]
pub enum Q2 {
    A(i32,),
    B(i32),
}

Error:

error[E0308]: mismatched types
 --> src/main.rs:9:10
  |
9 | #[derive(derive_more::Unwrap)]
  |          ^^^^^^^^^^^^^^^^^^^
  |          |
  |          expected `(i32,)`, found `i32`
  |          expected `(i32,)` because of return type
  |
  = note: expected tuple `(i32,)`
              found type `i32`
  = note: this error originates in the derive macro `derive_more::Unwrap` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use a trailing comma to create a tuple with one element
  |
9 | #[derive((derive_more::Unwrap,))]
  |          +                   ++

For more information about this error, try `rustc --explain E0308`.

Seems like macro incorrectly generates code that tries to unwrap tuple as inner value when comma is present. But A(i32,) is still enum variant with single type inside, not a tuple.

Deriving Unwrap for enums below work as expected (no error generated):

#[derive(derive_more::Unwrap)]
pub enum Q3 {
    A(i32,i32),
    B(i32),
}

#[derive(derive_more::Unwrap)]
pub enum Q4 {
    A(i32,i32,),
    B(i32),
}

[JelteF]

Could you try with version 1.0.0-beta.6? It has many fixes and we're getting quite close to the final 1.0 release.

[artslob]

@JelteF yes, this version works as expected

derive_more = { version = "1.0.0-beta.6", features = ["full"]}

[JelteF]

Great, closing this then as fixed