Open twilight-flower opened 2 years ago
@LunarTulip and I have just ran into this too. I have just been messing around with the generated code from the derive macro and I think that I could make some alterations to simplify and stabilize this behavior.
Hi!
The fix works well for the cases that were added as a test case but I believe the issue about the complex enum variant mentioned above is this present, i.e. the following struct:
#[derive(Debug, PartialEq, YaSerialize, YaDeserialize)]
enum Base {
Child {
#[yaserde(attribute)]
val: String
},
}
Fails to compile
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `=>`
--> yaserde/tests/enum.rs:231:30
|
231 | #[derive(Debug, PartialEq, YaSerialize, YaDeserialize)]
| ^^^^^^^^^^^ expected one of `.`, `;`, `?`, `}`, or an operator
|
= note: this error originates in the derive macro `YaSerialize` (in Nightly builds, run with -Z macro-backtrace for more info)
error: could not compile `yaserde` (test "enum") due to previous error
I believe the statement that results in the compile error is generated in this line, since changing it to an empty quote! {}
circumvents the issue (but also disables the serialization).
There's something weird going on with enum serialization. In particular, consider this source code:
The natural expected output for it would be something like this:
...however, what it actually outputs is this:
...in other words, the attribute gets dropped somehow.
The natural workaround for this, under other circumstances, would be to use a complex enum variant, like this:
...but, in fact, that will then lead to an error on attempted compilation, because the
yaserde(text)
derive macro doesn't work correctly for complex enum variants and throws an error instead.So it seems like there's no way to get attribute-serialization to work properly within enums at all. Is there some workaround to this that I'm currently missing?
(This is, of course, a simplified toy example for the sake of illustrating the problem. In my actual use case, there's more than one enum variant at work; I can't just swap the enum for a standalone struct, because it's important that I be able to get multiple different enum variants into the same vec.)