-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Provide Cargo messages as JSON messages #8283
Comments
Don't forget about other JSON-related formats for
Is it ok to mark build tool messages as messages from the compiler? (I'm talking about "compiler-message" reason)
Currently, in IJ-Rust we show only Also, in IJ-Rust we parse raw It would be nice to have JSON messages for these statuses. It's not necessary for IJ since we already have libtest support, but it may be useful for anyone else who wants to write it from scratch. Also, I think JSON messages for statuses should have "rendered" field like other diagnostic messages, in order to be able to show the "original" output in a separate window.
👍 , but I think it can be discussed in a separate issue after this issue is closed. |
In continuation of #8165 (comment)
Cargo already prints "unit count" (
For my purpose, I only need a number from 0 to 1 + some text to show (e.g., "Building a, b, c"), but as mentioned in #8165 (comment), an initial JSON message with the unit count + start / finish messages for each unit should be enough to calculate progress amount and list of active units.
I think single progression with different phases (
As I understand, Gradle downloads dependencies during the "compile" task ( |
I would love to have Cargo emit useful json messages as well. I was just looking at https://github.com/Nemo157/cargo-build-tree again and was wondering what would be required to actually have it support showing what was currently in-progress, having The fact that a |
It would be nice if all the json messages had a rendered field. The error and warning messages do but if you want to augment cargo in any way you have to parse all the messages and output the same things as cargo dose currently so it doesn't look unusual (except for the messages which already have a rendered field). Noticed the need for this in a couple of tools now so thought I would mention it in case it would be helpful also to others. |
# Description `substrate-wasm-builder` can be a build dependency for crates which develop FRAME runtimes. I had a tough time seeing errors happening in such crates (e.g. runtimes from the `templates` directory) in my IDE. I use a combination of rust-analyzer + nvim-lsp + nvim-lspconfig + rustacean.vim and all of this stack is not able to correctly parse errors emitted during the `build` phase. As a matter of fact there is also a cargo issue tracking specifically this issue where cargo doesn't propagate the `--message-format` type to the build phase: [here](rust-lang/cargo#14246) initially and then [here](rust-lang/cargo#8283). It feels like a solution for this use case isn't very close, so if it comes to runtimes development (both as an SDK user and developer), enabling wasm builder to emit diagnostics messages friendly to IDEs would be useful for regular workflows where IDEs are used for finding errors instead of manually running `cargo` commands. ## Integration It can be an issue if Substrate/FRAME SDKs users and developers rely on the runtimes' crates build phase output in certain ways. Emitting compilation messages as json will pollute the regular compilation output so people that would manually run `cargo build` or `cargo check` on their crates will have a tougher time extracting the non JSON output. ## Review Notes Rust IDEs based on rust-analyzer rely on cargo check/clippy to extract diagnostic information. The information is generated by passing flags like `--messages-format=json` to the `cargo` commands. The messages are extracted by rust-analyzer and published to LSP clients that will populate UIs accordingly. We need to build against the wasm target by using `message-format=json` too so that IDEs can show the errors for crates that have a build dependency on `substrate-wasm-builder`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
# Description `substrate-wasm-builder` can be a build dependency for crates which develop FRAME runtimes. I had a tough time seeing errors happening in such crates (e.g. runtimes from the `templates` directory) in my IDE. I use a combination of rust-analyzer + nvim-lsp + nvim-lspconfig + rustacean.vim and all of this stack is not able to correctly parse errors emitted during the `build` phase. As a matter of fact there is also a cargo issue tracking specifically this issue where cargo doesn't propagate the `--message-format` type to the build phase: [here](rust-lang/cargo#14246) initially and then [here](rust-lang/cargo#8283). It feels like a solution for this use case isn't very close, so if it comes to runtimes development (both as an SDK user and developer), enabling wasm builder to emit diagnostics messages friendly to IDEs would be useful for regular workflows where IDEs are used for finding errors instead of manually running `cargo` commands. ## Integration It can be an issue if Substrate/FRAME SDKs users and developers rely on the runtimes' crates build phase output in certain ways. Emitting compilation messages as json will pollute the regular compilation output so people that would manually run `cargo build` or `cargo check` on their crates will have a tougher time extracting the non JSON output. ## Review Notes Rust IDEs based on rust-analyzer rely on cargo check/clippy to extract diagnostic information. The information is generated by passing flags like `--messages-format=json` to the `cargo` commands. The messages are extracted by rust-analyzer and published to LSP clients that will populate UIs accordingly. We need to build against the wasm target by using `message-format=json` too so that IDEs can show the errors for crates that have a build dependency on `substrate-wasm-builder`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
# Description `substrate-wasm-builder` can be a build dependency for crates which develop FRAME runtimes. I had a tough time seeing errors happening in such crates (e.g. runtimes from the `templates` directory) in my IDE. I use a combination of rust-analyzer + nvim-lsp + nvim-lspconfig + rustacean.vim and all of this stack is not able to correctly parse errors emitted during the `build` phase. As a matter of fact there is also a cargo issue tracking specifically this issue where cargo doesn't propagate the `--message-format` type to the build phase: [here](rust-lang/cargo#14246) initially and then [here](rust-lang/cargo#8283). It feels like a solution for this use case isn't very close, so if it comes to runtimes development (both as an SDK user and developer), enabling wasm builder to emit diagnostics messages friendly to IDEs would be useful for regular workflows where IDEs are used for finding errors instead of manually running `cargo` commands. ## Integration It can be an issue if Substrate/FRAME SDKs users and developers rely on the runtimes' crates build phase output in certain ways. Emitting compilation messages as json will pollute the regular compilation output so people that would manually run `cargo build` or `cargo check` on their crates will have a tougher time extracting the non JSON output. ## Review Notes Rust IDEs based on rust-analyzer rely on cargo check/clippy to extract diagnostic information. The information is generated by passing flags like `--messages-format=json` to the `cargo` commands. The messages are extracted by rust-analyzer and published to LSP clients that will populate UIs accordingly. We need to build against the wasm target by using `message-format=json` too so that IDEs can show the errors for crates that have a build dependency on `substrate-wasm-builder`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
# Description `substrate-wasm-builder` can be a build dependency for crates which develop FRAME runtimes. I had a tough time seeing errors happening in such crates (e.g. runtimes from the `templates` directory) in my IDE. I use a combination of rust-analyzer + nvim-lsp + nvim-lspconfig + rustacean.vim and all of this stack is not able to correctly parse errors emitted during the `build` phase. As a matter of fact there is also a cargo issue tracking specifically this issue where cargo doesn't propagate the `--message-format` type to the build phase: [here](rust-lang/cargo#14246) initially and then [here](rust-lang/cargo#8283). It feels like a solution for this use case isn't very close, so if it comes to runtimes development (both as an SDK user and developer), enabling wasm builder to emit diagnostics messages friendly to IDEs would be useful for regular workflows where IDEs are used for finding errors instead of manually running `cargo` commands. ## Integration It can be an issue if Substrate/FRAME SDKs users and developers rely on the runtimes' crates build phase output in certain ways. Emitting compilation messages as json will pollute the regular compilation output so people that would manually run `cargo build` or `cargo check` on their crates will have a tougher time extracting the non JSON output. ## Review Notes Rust IDEs based on rust-analyzer rely on cargo check/clippy to extract diagnostic information. The information is generated by passing flags like `--messages-format=json` to the `cargo` commands. The messages are extracted by rust-analyzer and published to LSP clients that will populate UIs accordingly. We need to build against the wasm target by using `message-format=json` too so that IDEs can show the errors for crates that have a build dependency on `substrate-wasm-builder`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
Describe the problem you are trying to solve
When integrating Cargo with an editor or IDE, it is common to use JSON to get structured messages from
rustc
. However, Cargo's own messages (such as errors, warnings, etc.) are sent as plain text, making it difficult for the development environment to know how to display these messages.Describe the solution you'd like
It would be nice if Cargo's messages were sent as JSON when
--message-format=json
is used.Notes
There are many decisions to be made on the behavior and exact structure to use.
--message-format=json
? That could break or disrupt tools, though I'm not sure how likely that is, or what the consequences would be. Cargo could include something like rustc's--json
flag to configure JSON behavior, but it would be nice to avoid if possible to keep things simple."compiler-message"
structure for warnings and errors, or should it add a new one? It might be difficult to shoe-horn Cargo's format (which uses a stack of causes) to rustc's format. The drawback of using a separate structure is that then there would need to be multiple ways to handle "messages".cargo … --message-format json
should tell you when it starts compiling a cate. #12864)build.rs
warnings? What about-vv
output ofbuild.rs
(Build script warnings don't respect--message-format=json
. #14246)?The text was updated successfully, but these errors were encountered: