Help stabilize a subset of Macros 2.0!

[durka]

I agree with removing the separators if they’re going to be changed at all. If we actually improve the matchers, then the transition from macro_rules to macro won’t be so trivial, so I wouldn’t consider it a speed bump anymore.

[jjpe]

@matthewjasper Indeed that appears to be the case, thanks for that one!

I’ve got a slightly more complex case now, consider the code @ this playground link, which compiles.

If I uncomment the additional matcher arm in the inner macro, like so, I get an error:

   Compiling playground v0.0.1 (file:///playground)
error: attempted to repeat an expression containing no syntax variables matched as repeating at this depth
  --> src/main.rs:16:24
   |
16 |         ($foo:expr; [ $($arg:ident),* ]) => {
   |                        ^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

I have to be honest, I don’t know what’s happening here, as I’m almost sure I haven’t misnamed anything (there is an unused fragment $foo:expr but that should not cause any problems I think).

[CAD97]

The problem here is that the $()* repetition is being expanded by the outside macro instead of being interpreted as syntax to the inner macro.

Issue: nested macros don't allow repetitions in binding patterns

[jjpe]

I see, that is unfortunate.

I have left a post on the issue, but as it’s likely relevant to this thread: What can I do to get this moving forward? Is an RFC required?

EDIT: @durka provided a workaround for my issue here.

[alexcrichton]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.