-
-
Notifications
You must be signed in to change notification settings - Fork 384
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
Report compiler errors in machine readable format #2182
Conversation
63895e8
to
8c9c699
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #2182 +/- ##
==========================================
+ Coverage 64.80% 65.19% +0.39%
==========================================
Files 207 210 +3
Lines 20153 20468 +315
==========================================
+ Hits 13060 13344 +284
- Misses 5978 6003 +25
- Partials 1115 1121 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
TODO: test this with more compilers... |
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.
LGTM. The only think that I'm concerned about is that starting from now on this is something new that we need to maintain so here are some ideas for future PRs:
- Add more tests for different versions of compilers we're using.
- Adding fuzz testing in the parser might be helpful?
c618f3b
to
93e4e5b
Compare
93e4e5b
to
92aad00
Compare
92aad00
to
e40495d
Compare
The implementation has been rebased...
e40495d
to
d359feb
Compare
This will surely help. Adding a test is a tedious process tho...
Interesting, BTW I think that the fuzzer may not help to improve the parsing correctness because:
Anyway, it may help to test the parser's resistance to crazy inputs... |
7332338
to
57ad932
Compare
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'd like to have an integration test that checks for the new diagnostic
field.
If you want you can either:
- Expand the already existing integration test
internal/integrationtest/compile_3/compile_test.go|102 col 6| func TestCompilerErrOutput(t *testing.T) {
- Create a new one
Example:
TestCompilerErrOutput(t *testing.T) {
...
// prepare sketch
sketch, err := paths.New("testdata", "blink_with_wrong_cpp").Abs()
require.NoError(t, err)
// Run compile and catch err stream
out, _, err := cli.Run("compile", "-b", "arduino:avr:uno", "--format", "json", sketch.String())
...
requirejson.Query(t, out, `.diagnostics | length > 0`, `true`)
57ad932
to
86cde78
Compare
86cde78
to
4c9f2b0
Compare
Please check if the PR fulfills these requirements
See how to contribute
before creating one)
our contributing guidelines
UPGRADING.md
has been updated with a migration guide (for breaking changes)configuration.schema.json
updated if new parameters are added.What kind of change does this PR introduce?
Adds parsing of the compiler errors and warning to present them in a machine-readable way if JSON output is selected or if the
Compile
gRPC call is used.What is the current behavior?
The compiler output is presented as a big blob of text.
What is the new behavior?
The compiler output is dissected into a structured format so clients can easily consume it.
Does this PR introduce a breaking change, and is titled accordingly?
No
Other information
Fix #1121