Open aDotInTheVoid opened 5 months ago
Thanks for reporting this!
I worked on a fix but it appears to be a breaking change. Before, we moved the parser and the caller could declare their parsers as immutable. With this change, they now need to make their parsers mutable.
I'm assuming this can be worked around on the callers side by adding .by_ref()
on their side.
I'm thinking this is likely to not be enough to justify a breaking release right now but will need to wait until the motivation is strong enough to release one.
Side note: #502 only partially brings their behavior in alignment which is why I didn't mark this as a fix but a step. I suspect the way to fix this would be to stop using ().parse_next()
completely and instead assign each parse result to a variable using the same pre-filled list of variable names that the macros for implementing Parser
for tuples does. Hopefully this would let us reduce the scope of #237 affecting users of seq!
.
Please complete the following tasks
rust version
rustc 1.77.0 (aedd173a2 2024-03-17)
winnow version
0.6.5
Minimal reproducible code
Steps to reproduce the bug with the above code
cargo check
Actual Behaviour
Expected Behaviour
This should compile.
If
seq!
is used to make a struct (instead of a tuple) it does compile.works fine.
Additional Context
Manually expanding the
seq!
macro (with RA) for the broken example gives:This gives a more descriptive error:
Manually expanding the example that does work gives:
I think the reason this works is that
foo
andbar
don't need to be captured by value here, as.parse_next
takes&mut self
.Adding
.by_ref()
to the tuple example version may fix it.