Inconsistent pre-comment space when formatting tuples #4767
Labels
bug
Something isn't working
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 12, 2024
# Description ## Problem\* Resolves #4666 ## Summary\* Ensures that `nargo_fmt(nargo_fmt(source_code)) == nargo_fmt(source_code)`. Because we have expected outputs, we can avoid re-running on the unformatted inputs: ```rust nargo_fmt(expected_output) == expected_output ``` ### Bugs found - #4766 - #4767 - #4768 Currently failing on arrays and tuples: ```bash ---- tests::format_idempotent_array stdout ---- thread 'tests::format_idempotent_array' panicked at /Users/michaelklein/Coding/rust/noir/target/debug/build/nargo_fmt-14fb91f269fc38b6/out/execute.rs:3418:9: assertion failed: `(left == right)`' left: `"fn big_array() {\n [\n 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000, 1000000000000, 10000000000000, 100000000000000, 1000000000000000, 1..."` (truncated) right: `"fn big_array() {\n [\n 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 100000000, 1000000000, 10000000000, 100000000000, 1000000000000, 10000000000000, 100000000000000, 1000000000000000, 1..."` (truncated) Differences (-left|+right): [ // hello! 1, // asd - 10 + 10 // asdasd ]; [[[1, 2, 3], [4, 5, 6]], [[7, 8, 9], [10, 11, 12]], [[13, 14, 15], [16, 17, 18]]]; note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ---- tests::format_idempotent_tuple stdout ---- thread 'tests::format_idempotent_tuple' panicked at /Users/michaelklein/Coding/rust/noir/target/debug/build/nargo_fmt-14fb91f269fc38b6/out/execute.rs:776:9: assertion failed: `(left == right)`' left: `"fn main() {\n (1,);\n (// hello\n 1,);\n (/*hello*/ 1,);\n (1/*hello*/,);\n (1,);\n (/*test*/ 1,);\n (/*a*/ 1/*b*/,);\n (/*a*/ 1/*b*/, /*c*/ 2/*d*/, /*c*/ 2/*d*/);\n (/*a*/ 1/*..."` (truncated) right: `"fn main() {\n (1,);\n (// hello\n 1,);\n (/*hello*/ 1,);\n (1/*hello*/,);\n (1,);\n (/*test*/ 1,);\n (/*a*/ 1/*b*/,);\n (/*a*/ 1/*b*/, /*c*/ 2/*d*/, /*c*/ 2/*d*/);\n (/*a*/ 1/*..."` (truncated) Differences (-left|+right): (// 1,); (// 1 - 1,// 2, + 1, // 2, 2); (/*1*/ 1, /*2*/ 2); // FIXME: (((//2 1,),),); (/*a*/ - 1/*b*/, /*c*/ 2/*d*/, /*c*/ 2/*d*/, /*e*/ 3/*f*/); + 1/*b*/, +/*c*/ 2/*d*/, /*c*/ 2/*d*/, /*e*/ 3/*f*/); } ``` ## Additional Context ## 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: Tom French <15848336+TomAFrench@users.noreply.github.com>
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 22, 2024
# 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 <aakoshh@gmail.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
Running
nargo fmtintests::format_idempotent_tupleonly adds a space between the expression and comment when run twice:Expected Behavior
The tuple is successfully formatted with the space between the expression and comment when run the first time.
Bug
Space before comment only when running
nargo fmttwiceTo Reproduce
Project Impact
Nice-to-have
Impact Context
nargo fmtwith this type of bug can produce an unlimited number of trailing spaces.Workaround
Yes
Workaround Description
Manually add space after running
nargo fmtAdditional Context
No response
Installation Method
None
Nargo Version
No response
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: