Skip to content

better message for stray tokens after a ParseWrapper value - #225

Open
sunshowers wants to merge 1 commit into
jj-stack/handle-macro-rules-substitutions-across-the-codebase-ksmmqstofrom
jj-stack/better-message-for-stray-tokens-after-a-parsewrapper-value-rtkrpyvs
Open

better message for stray tokens after a ParseWrapper value#225
sunshowers wants to merge 1 commit into
jj-stack/handle-macro-rules-substitutions-across-the-codebase-ksmmqstofrom
jj-stack/better-message-for-stray-tokens-after-a-parsewrapper-value-rtkrpyvs

Conversation

@sunshowers

Copy link
Copy Markdown
Contributor

When a ParseWrapper<P> value is followed by tokens that P did not consume (for example bool_expr = true false), syn::parse2 rejected them with a bare "unexpected token" (though the span was fine). Produce a better error message in this case, similar to the message you would get from a non-ParseWrapper type.

Doing this in ParseWrapper rather than in individual Parse impls keeps those impls composable.

When a `ParseWrapper<P>` value is followed by tokens that `P` did not consume (for example `bool_expr = true false`), `syn::parse2` rejected them with a bare "unexpected token" (though the span was fine). Produce a better error message in this case, similar to the message you would get from a non-`ParseWrapper` type.

Doing this in `ParseWrapper` rather than in individual `Parse` impls keeps those impls composable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant