Consider depending on syn.features=["full"]

[ModProg]

Otherwise this would not work:

#[derive(derive_more::Debug)]
enum Enum {
    A = if cfg!(unix) { 2 } else { 3 },
}

error: proc-macro derive panicked
 --> src/main.rs:1:10
  |
1 | #[derive(derive_more::Debug)]
  |          ^^^^^^^^^^^^^^^^^^
  |
  = help: message: called `Result::unwrap()` on an `Err` value: Error("unsupported expression; enable syn's features=[\"full\"]")

[tyranron]

@ModProg that code is gross 😄

I would expect rather something like this:

#[derive(derive_more::Debug)]
enum Enum {
    #[cfg(unix)]
    A = 2,
    #[cfg(not(unix))]
    A = 3,
}

But yes, good catch. I guess we may provide a syn-full feature which enables "full" for syn for cases when someone requires it.

[JelteF]

I think assuming that we want the derive_more Debug derive to work for everything that the std Debug derive works for, then the debug feature of derive_more should depend on syn its full feature.

[JelteF]

How bad is compile time for syn its full feature, relative to what we have now?

[ModProg]

Well any of our derives that support enums have this problem. Because it happens when syn tries to parse the enum.

[JelteF]

Maybe this could be considered a bug in syn then?

[ModProg]

Maybe this could be considered a bug in syn then?

I guess, but I don't see how they could do it differently than adding a Expr::Unknown(TokenStream) and employing a lossy expr parser such as (https://docs.rs/proc-macro-utils/latest/proc_macro_utils/struct.TokenParser.html#method.next_expression).

Probably not in line with syns general approach to parsing.

Or they need to include all expressions in derive. But I guess they decided that some expressions are just highly unlikely to happen in this position.

[JelteF]

Do we need a dedicated feature for this in derive_more? Or does it work if the crate that contains the struct enables syn its "full" feature itself?

[tyranron]

@JelteF

Or does it work if the crate that contains the struct enables syn its "full" feature itself?

Yes, that works, of course. However, given that the derive_more is a proc-macro crate, library users unlikely will add syn to their dependencies just to enable full feature, if it's not there already due to other dependencies.

[JelteF]

This is fixed by syn upstream so closing this