feat: trait aliases #6431
feat: trait aliases #6431
Conversation
…mpl's for trait aliases, wip implementing impl generator
…to-many case, modify parse_item_kind to return multiple ItemKind's, generate a trait impl from the trait parser (when the trait alias is parsed), test generated impl's, test several cases in unit tests
…issue with where clauses, add docs, cargo clippy/fmt
github-actions
bot
added
the
documentation
|
🚀 Deployed on https://673798ec808ab53017c244bb--noir-docs.netlify.app |
| NoirTrait { | ||
| // Trait aliases: | ||
| // trait Foo<..> = A + B + E where ..; | ||
| let (bounds, where_clause, items, is_alias) = if self.eat_assign() { |
There was a problem hiding this comment.
Optional: instead of desugaring a trait alias in the parser itself, we could introduce a new AST node for it (maybe TraitAlias) and desugar it later on, maybe in the Elaborator or collector. That way:
- parsing is a bit simpler
- desugaring can be tested independently
- LSP or tools working with parsed code (like the formatter) don't need to know about how trait aliases are expanded, knowing that they need to skip the synthetic impl, and can focus on better handling this new node
There was a problem hiding this comment.
Oh, and it could be good to add a formatter test for this new syntax, to see if it works out of the box.
There was a problem hiding this comment.
I originally attempted to implement this by desugaring it in the Elaborator (based on the is_alias flag), but it was fairly complex to deal with post-parsing types.
- Testing this approach seems a bit simpler since we can check ~equality up to spans between the parsed trait impl and the expected desugaring.
I suppose adding an is_synthetic: bool to NoirTraitImpl would be easy if that helps handling it in the LSP?
Sure, I'll add a formatter test for this 👍
There was a problem hiding this comment.
@asterite I've added is_synthetic: bool to NoirTraitImpl and formatter support for trait aliases, with tests for both.
…bool parameter to NoirTraitImpl for synthetic impl's and test it
There was a problem hiding this comment.
Looks good to me. We've got a number of desugarings happening in the parser atm so I don't think it's blocking to have this here. We can always refactor this to how @asterite mentioned in a later PR.
| @@ -106,9 +109,9 @@ impl<'a> Parser<'a> { | |||
| /// | TypeAlias | |||
| /// | Function | |||
| /// ) | |||
| fn parse_item_kind(&mut self) -> Option<ItemKind> { | |||
| fn parse_item_kind(&mut self) -> Vec<ItemKind> { | |||
There was a problem hiding this comment.
Can you add a quick bit of signposting here that we expect this to return a vec of length 1 in 90% of cases and it's specifically for the case of traits that we may end up with both the trait definition and an impl?
Co-authored-by: Tom French <[email protected]>
|
FYI @noir-lang/developerrelations on Noir doc changes. |
Description
Problem*
Resolves #6315
Summary*
Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmton default settings.