4 ms·
I didn't actually try out the code, so I don't know whether it actually works regardless, but this looks really suspicious: = note: expanding `rpn! { @ op
by tomsmeding 9y ago
I didn't actually try out the code, so I don't know whether it actually works regardless, but this looks really suspicious:
= note: expanding `rpn! { @ op [ 4 , 3 + 7 , 2 ] * }`
= note: to `rpn ! ( [ 3 + 7 * 4 , 2 ] )`
Is that not, like, operator precedence gone really wrong? Or is this the rust stringifier in trace_macros messing up without anything going wrong in the actual AST?
- agumonkey 9y agoI'd say macroexpansion is precedence agnostic. folding * over 4, 3+7, 2 */ 4, 3+7, 2 */ 3+7 * 4, 2 */ 2 * 3+7 * 4 => 2 * 3 + 7 * 4 so basically, beware
- dbaupp 9y agoThe trace_macros! stringifier isn't inserting parens when required: due to the use of 'expr' the macro is treating 3 + 7 as a single node X, and then the multiplication with 4 is, in the AST, X * 4 (i.e. correct). The thing that is being printed there is the recursive rpn invocation in the @op branch, and specifically the '$a $op $b', which is a "disconnected" sequence of AST items/token trees. Once it's forced to be parsed as an expression (that is, when matched against the recursive '$... : expr' rules), the printer handles it correctly. For instance, the last 'to' line of the output in the example you quote, or, if that example is changed to 'rpn!(2 3 7 + 4 * 5)', the trace_macros output includes: ... = note: to `rpn ! ( [ 5 , (3 + 7) * 4 , 2 ] )` = note: expanding `rpn! { [ 5 , (3 + 7) * 4 , 2 ] }` ...