Skip to content

/RustyCode

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

Add support for JSON error format and new (RUST_NEW_ERROR_FORMAT=true) error style #159

Merged
merged 3 commits into from Aug 5, 2016

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@trixnz @saviorisdead @isg
@trixnz
Copy link
Contributor

trixnz commented Aug 2, 2016 •
edited

The Cargo output is somewhat preserved by manually emitting Rust formatted errors, although it is not a complete solution. It does, however, provide a much better output than a giant JSON blob.

As per the discussion in #146, this uses RUSTFLAGS while the error-format feature is unstable. Hopefully error-format makes its way into Cargo so we can issue JSON builds from the IDE without RUSTFLAGS as this currently invalidates the internal fingerprint in rustc.

I've also refactored the error parsing to be a little more generic so future additions (like parsing the new Rust error format) can be added trivially.

_Edit:_ Went ahead and added support for the new error format (RUST_NEW_ERROR_FORMAT=true) that is set to become the new default in the future.
@trixnz
Add support for JSON error format via the `useJsonErrors` config flag 
The Cargo output is somewhat preserved by manually emitting Rust formatted errors
Loading status checks…
7edc301

@trixnz trixnz referenced this pull request Aug 2, 2016

Open

Possible Rust error format updates and IDE support #146

trixnz added some commits Aug 3, 2016

@trixnz
Changed error list to only contain the primary span as VSCode orders … 
…the problem list by the error's range, which can cause a lot of confusion if there are duplicate messages.
Loading status checks…
f7da7ea
@trixnz
Added support for the new error format (RUST_NEW_ERROR_FORMAT). Fixes #… 
…130
Loading status checks…
b5d5517

@trixnz trixnz changed the title Add support for JSON error format via the `useJsonErrors` config flag Add support for JSON error format and new (RUST_NEW_ERROR_FORMAT=true) error style Aug 3, 2016

@trixnz

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

trixnz commented Aug 3, 2016

This should now be good to go. It adds rust.useJsonErrors for the unstable JSON style output as well as rust.useNewErrorFormat for those slick new errors 😛.
@saviorisdead

This comment has been minimized.

Sign in to view
Copy link
Owner

saviorisdead commented Aug 5, 2016

This is awesome 👍

@saviorisdead saviorisdead merged commit de7be5d into saviorisdead:master Aug 5, 2016
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jonathandturner jonathandturner referenced this pull request Aug 5, 2016

Merged

Turn on new errors and json mode #35401

bors added a commit to rust-lang/rust that referenced this pull request Aug 9, 2016

@bors
Auto merge of #35401 - jonathandturner:enable_json_and_new_errors, r=… 
…nikomatsakis

Turn on new errors and json mode

This PR is a big-switch, but on a well-worn path:

* Turns on new errors by default (and removes old skool)
* Moves json output from behind a flag

The RFC for new errors [landed](rust-lang/rfcs#1644) and as part of that we wanted some bake time.  It's now had a few weeks + all the time leading up to the RFC of people banging on it.  We've also had [editors updating to the new format](saviorisdead/RustyCode#159) and expect more to follow.

We also have an [issue on old skool](#35330) that needs to be fixed as more errors are switched to the new style, but it seems silly to fix old skool errors when we fully intend to throw the switch in the near future.

This makes it lean towards "why not just throw the switch now, rather than waiting a couple more weeks?"  I only know of vim that wanted to try to parse the new format but were not sure how, and I think we can reach out to them and work out something in the 8 weeks before this would appear in a stable release.

We've [hashed out](#35330) stabilizing JSON output, and it seems like people are relatively happy making what we have v1 and then likely adding to it in the future.  The idea is that we'd maintain backward compatibility and just add new fields as needed.  We'll also work on a separate output format that'd be better suited for interactive tools like IDES (since JSON message can get a little long depending on the error).

This PR stabilizes JSON mode, allowing its use without `-Z unstable-options`

Combined, this gives editors two ways to support errors going forward: parsing the new error format or using the JSON mode.  By moving JSON to stable, we can also add support to Cargo, which plugin authors tell us does help simplify their support story.

r? @nikomatsakis
cc @rust-lang/tools
beb9d61

bors added a commit to rust-lang/rust that referenced this pull request Aug 9, 2016

@bors
Auto merge of #35401 - jonathandturner:enable_json_and_new_errors, r=… 
…jonathandturner

Turn on new errors and json mode

This PR is a big-switch, but on a well-worn path:

* Turns on new errors by default (and removes old skool)
* Moves json output from behind a flag

The RFC for new errors [landed](rust-lang/rfcs#1644) and as part of that we wanted some bake time.  It's now had a few weeks + all the time leading up to the RFC of people banging on it.  We've also had [editors updating to the new format](saviorisdead/RustyCode#159) and expect more to follow.

We also have an [issue on old skool](#35330) that needs to be fixed as more errors are switched to the new style, but it seems silly to fix old skool errors when we fully intend to throw the switch in the near future.

This makes it lean towards "why not just throw the switch now, rather than waiting a couple more weeks?"  I only know of vim that wanted to try to parse the new format but were not sure how, and I think we can reach out to them and work out something in the 8 weeks before this would appear in a stable release.

We've [hashed out](#35330) stabilizing JSON output, and it seems like people are relatively happy making what we have v1 and then likely adding to it in the future.  The idea is that we'd maintain backward compatibility and just add new fields as needed.  We'll also work on a separate output format that'd be better suited for interactive tools like IDES (since JSON message can get a little long depending on the error).

This PR stabilizes JSON mode, allowing its use without `-Z unstable-options`

Combined, this gives editors two ways to support errors going forward: parsing the new error format or using the JSON mode.  By moving JSON to stable, we can also add support to Cargo, which plugin authors tell us does help simplify their support story.

r? @nikomatsakis
cc @rust-lang/tools

Closes #34826
576f766
@isg

This comment has been minimized.

Sign in to view
Copy link

isg commented on b5d5517 Aug 10, 2016

Thank you for doing this! Much appreciated :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.