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
Support function receivers self
, mut self
, &self
, &mut self
#27
Support function receivers self
, mut self
, &self
, &mut self
#27
Conversation
Always a pleasure to get a high-quality PR =) From a quick read-through, everything looks good. I'll look at it again and (presumably) merge it before the end of the week. |
18c920e
to
da2511f
Compare
Thanks a lot for the kind words 😊 |
Renew insta snapshots for function parsing Added: * Function::tk_params_parens -- () around parameter lists * Function::tk_return_arrow -- -> before return type * FunctionParameter::tk_colon -- : between parameter name + type
da2511f
to
74582bc
Compare
Just a quick note to say I didn't forget about this PR. Still hoping to merge it and the other one soon. |
No worries, and thanks for the heads-up! One thing I was wondering when working on the other PR: would it make sense to use shorter identifiers, since this got quite long with the "Receiver"/"Typed" addition -- also for consistency with other identifiers like pub enum FunctionParameter { ... }
pub struct FunctionReceiverParameter { ... }
pub struct FunctionTypedParameter { ... } there could be pub enum FnParam { ... }
pub struct FnReceiverParam { ... }
pub struct FnTypedParam{ ... } If yes, I could do that either here or in a separate follow-up "consistency PR". Other types might have similar points. |
I'd lean towards doing it once both PRs are merged. |
Sounds good to me! |
Some feedback:
Overall, none of these are blockers, so I'm merging the PR now. |
Thanks a lot for the merge and the feedback!
I see, but this is currently not done consistently -- e.g. Slightly off-topic, what do you think about translating those panics into To clarify, in my own code (that uses venial), I wrote this little utility: type ParseResult<T> = Result<T, venial::Error>;
pub fn fail<R, T>(msg: &str, tokens: T) -> ParseResult<R>
where
T: Spanned,
{
Err(venial::Error::new_at_span(tokens.__span(), msg))
} Usage: fn try_parse(...) -> ParseResult<...> {
// ...
match tk {
TokenTree::Ident(ident) => {
let key = /* extract stuff, etc */
}
_ => fail("attribute must start with key", tk)?,
}
} Non-panicking functions would also help the problem mentioned here: when encountering Edit: after some more thought, it might actually be quite a bit of effort, since it's not just the direct Your other points should be clear, I'll integrate them as a separate commit in the |
Adds support for receiver parameters
self
,mut self
,&self
,&mut self
.Also captures several "non-content" tokens like
( )
parameter list group,:
parameter name-value separator,->
return type separator.This PR contains breaking changes, as it splits
FunctionParameter
up: