-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Better typed api #105
Better typed api #105
Conversation
That was a lot of work but I think I finished. |
I'm going to remove |
Co-authored-by: Alain Zscheile <[email protected]>
Co-authored-by: Alain Zscheile <[email protected]>
Tests should be ported before this should/can be merged. |
The tests should be ported already, hence the massive diff |
Also |
- Try to make the macro syntax more rust like. - impl blocks should be written - Implementing a trait that has all defaults should be done by hand
Co-authored-by: Alain Zscheile <[email protected]>
examples/list-fns.rs
Outdated
@@ -1,6 +1,20 @@ | |||
use std::{env, error::Error, fs}; | |||
|
|||
use rnix::{types::*, NodeOrToken, SyntaxKind::*, SyntaxNode}; | |||
use rnix::ast::AstToken; |
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.
use rnix::ast::AstToken; |
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.
Fixed.
src/ast.rs
Outdated
pub(super) fn children_tokens<N: AstNode>(parent: &N) -> impl Iterator<Item = SyntaxToken> { | ||
parent.syntax().children_with_tokens().filter_map(SyntaxElement::into_token) | ||
} | ||
|
||
pub(super) fn children_tokens_u<N: AstNode>(parent: &N) -> impl Iterator<Item = SyntaxToken> { | ||
parent.syntax().children_with_tokens().filter_map(SyntaxElement::into_token) | ||
} |
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.
what is the intended difference between these two functions? The first one should ne ,pre typed, right? But it currently isn't?
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.
I guess this is fixed now.
pub fn from_kind(token: SyntaxKind) -> Option<Self> { | ||
match token { | ||
TOKEN_CONCAT => Some(BinOpKind::Concat), | ||
TOKEN_QUESTION => Some(BinOpKind::IsSet), | ||
TOKEN_UPDATE => Some(BinOpKind::Update), | ||
|
||
TOKEN_ADD => Some(BinOpKind::Add), | ||
TOKEN_SUB => Some(BinOpKind::Sub), | ||
TOKEN_MUL => Some(BinOpKind::Mul), | ||
TOKEN_DIV => Some(BinOpKind::Div), | ||
|
||
TOKEN_AND => Some(BinOpKind::And), | ||
TOKEN_EQUAL => Some(BinOpKind::Equal), | ||
TOKEN_IMPLICATION => Some(BinOpKind::Implication), | ||
TOKEN_LESS => Some(BinOpKind::Less), | ||
TOKEN_LESS_OR_EQ => Some(BinOpKind::LessOrEq), | ||
TOKEN_MORE => Some(BinOpKind::More), | ||
TOKEN_MORE_OR_EQ => Some(BinOpKind::MoreOrEq), | ||
TOKEN_NOT_EQUAL => Some(BinOpKind::NotEqual), | ||
TOKEN_OR => Some(BinOpKind::Or), | ||
|
||
_ => None, | ||
} | ||
} |
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.
imo this should be a core::convert::TryFrom
impl
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.
postponed.
pub fn from_kind(kind: SyntaxKind) -> Option<Self> { | ||
match kind { | ||
TOKEN_INVERT => Some(UnaryOpKind::Invert), | ||
TOKEN_SUB => Some(UnaryOpKind::Negate), | ||
_ => None, | ||
} | ||
} |
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 should also be a TryFrom
impl
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.
postponed.
I think any problems with |
ok |
we do have indeed a problem with |
I wonder if we should be using |
We could also try |
I think this is basically ready. This pr is really big and I don't want it to drag on forever. It doesn't have to be perfect, as we can make followup prs. I think currently it is good enough. I want to get this in so I can merge other prs. So @oxalica @darichey @zseri final round of comments before I merge? |
Would you mind summarizing the changes in here, especially the breaking things? I actually wanted to review it as well, however I didn't have the time for it last week, next week perhaps. The thing is, this may be fine implementation-wise, but to me it seems as if this change was punched through way too fast. Talking about the API changes etc. first might've been preferable. |
I understand your concern, but we talked about the api a lot before merging this, hence the massive comment length. This pr was here for more than a year, and I didn't want to wait any longer, so I don't think it was too fast. Summary
|
Continuation of #36