-
Notifications
You must be signed in to change notification settings - Fork 385
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
feat: printing all the errors from goparser #2011
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2011 +/- ##
==========================================
+ Coverage 49.01% 49.02% +0.01%
==========================================
Files 576 576
Lines 77604 77617 +13
==========================================
+ Hits 38040 38055 +15
+ Misses 36481 36480 -1
+ Partials 3083 3082 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Great addition! It's definitely needed. Could you simplify the implementation? |
b48aafc
to
baf5cef
Compare
Thank you for your contribution! |
58ccdf1
to
91a66af
Compare
Just a little remark on this PR, This happens when having errors on different files I would be glad to work on this again in order to have all errors on all folder files something more Go like |
Feel free to make a follow up :) |
This Pull request intents to follow up on #2011. As said on that Pull request, currently we show all lint errors on the first analyzed file. If in a folder we have `a.gno` & `b.gno` both with lint errors. `gno lint | run | test` will only find the errors related to one of those files. **This PR aims to show all the lint errors present on the current folder**. Changes: for lint & test cmd: - we modified ParseMemPackage function on gnovm/pkg/gnoland/nodes.go. Before this function returned as soon as an error was found while Parsing the gno file. So we introduced an error slice to keep track of all Parse errors. After parsing all the files we panic with the list of errors only if this list is not empty. - we did the same on parseMemPackageTests function - create a function printRuntimeError that handles the print of the errors inside `catchRuntimeError` function. We did this change in order to be able to recursively call the funtion and handle the case of an []error type composed of scanner.ErrorList errors. ### Results * running on gnovm/tests/integ/several-files-multiple/errors LINT (before): ```sh several-files-multiple-errors % gno lint . file2.gno:3: expected 'IDENT', found '{' (code=2). file2.gno:5: expected type, found '}' (code=2). ``` LINT (after): ```sh gno lint . file2.gno:3: expected 'IDENT', found '{' (code=2). file2.gno:5: expected type, found '}' (code=2). main.gno:5: expected ';', found example (code=2). main.gno:6: expected '}', found 'EOF' (code=2). exit status 1 ``` <!-- please provide a detailed description of the changes made in this pull request. --> <details> <summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
This PR aims to print all the errors that are found by the go/parser package.
Currently the
parser.ParseFile
function returns anscanner.ErrorList
object that only prints the first error and a count of the remaining errors. #1933 everything is better explained here.For the changes this PR introduces:
gnovm/cmd/gno/lint.go.catchRuntimeError
to handle and print all errors of an error with typescanner.ErrorList
panic(errors.Wrap(err, "parsing file "+mfile.Name))
here err has the type scanner.ErrorList but as we're wrapping it it would be more complex and difficult to read on catchRuntimeError to identify an error with the type ErrorListResults: (Using issue example)
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description