-
Notifications
You must be signed in to change notification settings - Fork 213
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
# Description ## Problem Resolves #5281 Resolves #4768 Resolves #4767 Resolves #4766 Resolves #4558 Resolves #4462 Resolves #3945 Resolves #3312 ## Summary I thought about trying to extend the existing formatter to format more code, but I couldn't understand it very well: it partially implemented things, and it lacked comments and some explanation of how it works. I think some chunks might have been copied from the Rust formatter. I also took a look into it but though it might be too complex. [I wrote a formatter in the past for Crystal](https://github.com/crystal-lang/crystal/blob/master/src/compiler/crystal/tools/formatter.cr) with a technique that I saw was used in the Java formatter written for Eclipse. The idea is to traverse the AST together with a Lexer, writing things along the way, bumping into comments and formatting those, etc. It works pretty well! But that's not enough for the Noir formatter because here we also want to automatically wrap long lines (Crystal's formatter doesn't do that). That part (wrapping) is partially based on [this excellent blog post](https://yorickpeterse.com/articles/how-to-write-a-code-formatter/). Benefits: - All code kinds are formatted. For example previously traits weren't formatted. - Comments are never lost. - Lambdas appearing as the last argument of a call are formatted nicely (this was maybe the most trickier part to get right). - I believe the new code ends up being simpler than before, even though it's (slightly) longer (previously is was 2138 lines, now it's 6139, though 2608 lines are tests, so it ends up being 3531 lines, but this new formatter does many things the old one didn't). I tried to comment and document it well. - Adding new formatting rules, new configurations, or enabling formatting of new syntax should be relatively easy to do. - There are lots and lots of tests for each of the different scenarios. The existing overall formatter tests were kept, but with unit tests it's easier to see how edge cases are formatted. [Here's Aztec-Packages formatted with the new formatter](https://github.com/AztecProtocol/aztec-packages/pull/9292/files): - Max line width seems to be respected more (making it more readable) - `unsafe { ... }` and `comptime { ... }` expressions will be inlined if possible (shortening the code and making it more readable) ## Additional Context Some things are subjective. For example Rust will put a function `where` clause in a separate line, with each trait bound on its own line. The new formatter does that too. But Rust will sometimes put an `impl` where clause on the same line. It's not clear to me why. I chose to always put `where` clauses on a separate line, but this could easily be changed if we wanted to. ## Documentation Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist - [x] I have tested the changes locally. - [x] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings. --------- Co-authored-by: Akosh Farkash <[email protected]> Co-authored-by: Tom French <[email protected]>
- Loading branch information
1 parent
70dcf4a
commit 62404d7
Showing
315 changed files
with
14,620 additions
and
4,712 deletions.
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.