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.
1 Like
@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).
The problem here is that the $()* repetition is being expanded by the outside macro instead of being interpreted as syntax to the inner macro.
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?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.