-
-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade syn to 2.0 #404
Upgrade syn to 2.0 #404
Conversation
@bilelmoussaoui any chance you can take over? |
Can you please elaborate on this? |
I'm talking about this change. It impacts error messages, e.g. supplying |
Thanks for explaining. 👍
Yeah. The new error seems more descriptive even. My preference would always bee what's most helpful to the user. |
b20513e
to
562b76d
Compare
// Since signals do not have a function body, they don't parse as ImplItemFn… | ||
ImplItem::Verbatim(tokens) => { | ||
// … thus parse them ourselves and construct an ImplItemFn from that | ||
let decl = syn::parse2::<ImplItemSignal>(tokens.clone())?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the hardest piece to find out. Apparently syn 1.x just accepted ImplItemMethod
s without a body, but syn 2.x does not. The error message when re-emitting this ImplItem::Verbatim
was plenty confusing (it was "expected impl
" on the first token of the item).
Closing in favour of #798. |
Didn't convert the huge
macro_rules!
macro and some non-trivialNestedMeta
usage. I'd rather just convert it to parsing in one step like I did formatch_attribute_with_str_list_value
, but (a) I expected this to be a short contribution and have run out of time for now and (b) I'm not sure this is even what you want, so let's discuss how to proceed from this draft PR.Resolved #401.