Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRust error format updates and IDE support #130
Comments
This comment has been minimized.
This comment has been minimized.
tupshin
commented
Aug 11, 2016
|
I just came here to file a bug against RustDT, if there wasn't one already. I am using nightly, to take advantage of a number of features, and just did a "rustup update" which got me the new error format. And yes, RustDT fails to detect errors at all now, so nothing is populated in the Tasks pane of eclipse. I would love a fix to this, as these new error messages have already helped me track down a couple of errors that had been plaguing me for days. Thanks for that, btw. :D |
This comment has been minimized.
This comment has been minimized.
|
Ok, I'll try to look at this soon when I have the time. If you wanna have a stab at in the meawhile, it's https://github.com/RustDT/RustDT/blob/master/plugin_tooling/src-tests/com/github/rustdt/tooling/RustBuildOutputParserTest.java |
This comment has been minimized.
This comment has been minimized.
|
I'm currently working on this. |
PieterPenninckx
referenced this issue
Sep 8, 2016
Merged
Added copy constructor for ToolMessageData. #7
This comment has been minimized.
This comment has been minimized.
Cool, I've been busy with loads of stuff, haven't been able to look into this. |
This comment has been minimized.
This comment has been minimized.
|
Great! I was trying to remember to mention that we're about 16 days away from the Rust 1.12, which will have the new errors on by default (and the old error format removed). It also has stable JSON, so that's also available. |
This comment has been minimized.
This comment has been minimized.
|
Ok. I created a branch that works for me at least for the nightly version of Rust that I downloaded some time ago. I will have to re-test with a more recent version. It parses the Json format. The parser for the old format is still there. Based upon the compiler flags (environment variable, actually), it determines which parser to use. In Eclipse, the user has to set the environment variable I've been busy with other things this week and I will still be busy today. But for tomorrow, I plan to re-test with a more recent version of the compiler and to propose a more user-friendly solution to determine which error parser to use. |
This comment has been minimized.
This comment has been minimized.
|
It still works with the most recent nightly :-) I have a proposal for deciding which error output format to use (edit: see also my comment from October 3):
@bruno-medeiros is this ok for you? I don't know how much time I will have for this, so I'll focus on creating a pull request for the not-so-user-friendly solution first. Edit: fixed version numbers as pointed out by jonathandturner. |
This comment has been minimized.
This comment has been minimized.
|
Just one note - 1.12 will be the first with new errors and stable JSON, not 1.13. (what's in nightly now will become beta for a cycle and then be released sometime in November) |
This was referenced Sep 16, 2016
This comment has been minimized.
This comment has been minimized.
|
It seems like I won't find the time to write code for automatically switching to the correct output parser. Maybe better leave as-is, and just update the default settings for the environment variable so that it works out-of-the-box for rustc 1.12 and above + add some documentation how you can change the environment variable settings if you want to use rustc 1.11 or below. |
This comment has been minimized.
This comment has been minimized.
|
I was just looking at rust-lang/cargo#2982 to get acquanted with how the new error format works. And yeah, @PieterPenninckx don't bother trying to detect correct output parser. Just make it work for rustc 1.2 (which is out now, and I imagine the vast majority of people will be using 1.2 or above). If someone happens to need to use 1.11, they can modify the environment variable settings, like you said. The RustDT parser can just detect which one format to use (for example, if line begin with "{", it's json, otherwise, old format. According to RustyCode devs, that's what they've been doing, so it works.) Anyways, onwards to reviewing the PR |
bruno-medeiros
closed this
in
9a22f79
Oct 11, 2016
This comment has been minimized.
This comment has been minimized.
|
Thanks @PieterPenninckx for the PR, now just needs some more testing before a release is made. If anyone wants to try it out already, you can build RustDT yourselves, all you need is Maven (https://github.com/RustDT/RustDT#automated-building-and-testing), and you will get a local update site |
This comment has been minimized.
This comment has been minimized.
tupshin
commented
Oct 11, 2016
|
I did a fresh checkout of the source a couple of minutes ago, and mvn -e verify gives me |
This comment has been minimized.
This comment has been minimized.
|
Yeah I forgot to run the tests before commiting |
This comment has been minimized.
This comment has been minimized.
|
Note that if Cargo starts building multiple targets, it is likely RustDT with fail to parse the messages due to this issue: rust-lang/rust#37011 |
This comment has been minimized.
This comment has been minimized.
tupshin
commented
Oct 11, 2016
|
Thanks much for this. I am still getting a test error when running verify, but I can also confirm that this version does work with the new format and is picking up my errors, displaying them in the problems tab, etc.
|
This comment has been minimized.
This comment has been minimized.
|
@tupshin That's odd, my my local tests (Windows machine) and the Travis-CI build complete successfully, no test failures. |
jonathandturner commentedAug 8, 2016
We've been working to create a new error output format. These initial tests have gone well, and we're currently discussing making this the default error format. Once this switch is thrown, there are still some weeks before this gets released in a stable release. We hope to make the transition as smooth as possible for IDE plugins.
The PR mentioned above also enables a supported JSON output mode that contains the information used in the error message. We're hoping this mode will give plugins more options to choose from for how the support errors.
Feel free to jump in on the thread if this impacts your plugin, and let us know how we can help.