Fix relationship macro for multiple named members fields

[krunchington]

Objective

Fixes #18466

Solution

Updated the macro generation pattern to place the comma in the correct place in the pattern.

Testing

• Tried named and unnamed fields in combination, and used rust expand macro tooling to see the generated code and verify its correctness (see screenshots in example below)

---

Showcase

Screenshot showing expanded macro with multiple named fields

Screenshot showing expanded macro with single unnamed field

Migration Guide

n/a

[alice-i-cecile]

Good fix, but needs a regression test please :)

[krunchington]

Good fix, but needs a regression test please :)

Gotcha I'm not familiar with testing macros but I'll poke around in this tmrw night if I can get time!

[alice-i-cecile]

For a test, just add some dead code in a struct that checks that this compiles. Or use a doc test, which can be a bit nicer.

[krunchington]

For a test, just add some dead code in a struct that checks that this compiles. Or use a doc test, which can be a bit nicer.

Got it, sounds straightforward!

[CHATALOT1]

Having tested with my own similar error case, I believe the same fix is necessary on line 781 also to avoid the same bug occurring in the relationship_target macro.

[Bleachfuel]

woops sorry, messed up when implementing it for enum's

[Bleachfuel]

Also for line 781

[krunchington]

Having tested with my own similar error case, I believe the same fix is necessary on line 781 also to avoid the same bug occurring in the relationship_target macro.

Good catch!

[krunchington]

Extra case handled in derive_relationship_target, and I added doc tests. I didn't put much extra doc content in them though because they're private and so don't show on the public crates docsite I believe? I also had to add bevy_ecs as a dev dependency to handle this case for the imports.

[krunchington]

Hm, these CI failures don't look related to my change. Did I inherit them by rebasing against main?

They're all in the bevy_reflect crate which I didn't touch

[mockersf]

Hm, these CI failures don't look related to my change. Did I inherit them by rebasing against main?

They're all in the bevy_reflect crate which I didn't touch

I think it's because you're changing a macro crate which are compiled differently. And you can't depend on bevy_ecs in it. so you should probably move your examples to bevy_ecs

[krunchington]

I think it's because you're changing a macro crate which are compiled differently. And you can't depend on bevy_ecs in it. so you should probably move your examples to bevy_ecs

Thanks. I opted for actual test content rather than adding a bunch of cases to doc tests that might just be noise. Hoping this covers the cases appropriately but happy to adjust if folks have suggestions for alternate approaches!