@@ -155,17 +155,22 @@ If it is under more, it'll be repeated, as appropriate.
155
155
156
156
## Parsing limitations
157
157
158
- The macro parser will parse Rust syntax with two limitations:
159
158
160
- 1 . The parser will always parse as much as possible. For example, if the comma
161
- were omitted from the syntax of ` early_return! ` above, ` input_1 [ ` would've
162
- been interpreted as the beginning of an array index. In fact, invoking the
163
- macro would have been impossible.
164
- 2 . The parser must have eliminated all ambiguity by the time it reaches a
159
+ For technical reasons, there are two limitations to the treatment of syntax
160
+ fragments by the macro parser:
161
+
162
+ 1 . The parser will always parse as much as possible of a Rust syntactic
163
+ fragment. For example, if the comma were omitted from the syntax of
164
+ ` early_return! ` above, ` input_1 [ ` would've been interpreted as the beginning
165
+ of an array index. In fact, invoking the macro would have been impossible.
166
+ 2 . The parser must have eliminated all ambiguity by the time it reaches a
165
167
` $name:fragment_specifier ` declaration. This limitation can result in parse
166
168
errors when declarations occur at the beginning of, or immediately after,
167
- a ` $(...)* ` . Changing the invocation syntax to require a distinctive
168
- token in front can solve the problem.
169
+ a ` $(...)* ` . For example, the grammar ` $($t:ty)* $e:expr ` will always fail to
170
+ parse because the parser would be forced to choose between parsing ` t ` and
171
+ parsing ` e ` . Changing the invocation syntax to require a distinctive token in
172
+ front can solve the problem. In the above example, ` $(T $t:ty)* E $e:exp `
173
+ solves the problem.
169
174
170
175
## A final note
171
176
0 commit comments