Skip to content
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

fix: correct error count for cargo check --message-format json #14598

Merged
merged 1 commit into from
Sep 27, 2024

Conversation

yichi170
Copy link
Contributor

Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!
(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)

This PR resolves the issue with incorrect error count and ensures warnings are correctly displayed when using cargo check --message-format json.

Fixes #14472

@rustbot
Copy link
Collaborator

rustbot commented Sep 26, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added A-build-execution Area: anything dealing with executing the compiler S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 26, 2024
src/cargo/core/compiler/mod.rs Show resolved Hide resolved
src/cargo/core/compiler/mod.rs Outdated Show resolved Hide resolved
@epage
Copy link
Contributor

epage commented Sep 26, 2024

Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!

Welcome!

If you ever want some face-time with a Cargo team member, we hold office hours on jitsi, see https://github.com/rust-lang/cargo/wiki/Office-Hours

It would be great if this change could have a test! Looking around, my guess is one of the following files will have relevant tests to put this next to: tests/testsuite/check.rs, tests/testsuite/message_format.rs, or tests/testsuite/messages.rs.

Something we've found very helpful when writing tests is to add them in a commit before a fix, with every commit passing the test. See https://doc.crates.io/contrib/process/working-on-cargo.html#submitting-a-pull-request for more details.

(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)

We don't have an official style though some of us use Conventional Commits

@yichi170
Copy link
Contributor Author

Thanks for providing the information! I would add the test for this modification.

@yichi170 yichi170 force-pushed the correct-error-count branch 2 times, most recently from 90f84e3 to 34b3326 Compare September 26, 2024 20:53
@yichi170
Copy link
Contributor Author

yichi170 commented Sep 27, 2024

I think the original test already cover this PR, instead of creating one, I modify the test to make it produce the correct result.
If there is anything that I can do, please let me know!

Copy link
Member

@weihanglo weihanglo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah existing tests seem to cover the case.

}
if let Ok(message) = serde_json::from_str::<CompilerMessage>(compiler_message.get()) {
count_diagnostic(&message.level, options);
if let Ok(msg) = serde_json::from_str::<CompilerMessage>(compiler_message.get()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of reusing a larger struct definition, should we just add an extra field message, and change count_diagnostic to accept three args (level, message, options) ?

Although having no data, my intuition tells me that skipping unused fields is generally more performant.

{
  "rendered": "error: expected one of `!` or `::`, found `<eof>`\n --> src/main.rs:3:1\n  |\n3 | xxx\n  | ^^^ expected one of `!` or `::`\n\n",
  "children": [], // may contain nested diagnostics
  "level": "error",
  "message": "expected one of `!` or `::`, found `<eof>`",
}

compares to

{
  "level": "error",
  "message": "expected one of `!` or `::`, found `<eof>`",
}

Copy link
Contributor Author

@yichi170 yichi170 Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we just add an extra field message, and change count_diagnostic to accept three args (level, message, options) ?

Do you mean we should check the message in count_diagnostic instead of checking before passing the (level, options) to count_diagnostic?

Copy link
Member

@weihanglo weihanglo Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignore the count_diagnostic part. I have no idea what I was talking about.

I meant that we may want to keep a separate CompilerMessage struct definition, since the current patch deserializes more fields than needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

@weihanglo
Copy link
Member

Awesome! Thanks for helping.

@bors r+

@bors
Copy link
Contributor

bors commented Sep 27, 2024

📌 Commit 71c830c has been approved by weihanglo

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 27, 2024
@bors
Copy link
Contributor

bors commented Sep 27, 2024

⌛ Testing commit 71c830c with merge a3b35a0...

@bors
Copy link
Contributor

bors commented Sep 27, 2024

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing a3b35a0 to master...

@bors bors merged commit a3b35a0 into rust-lang:master Sep 27, 2024
22 checks passed
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 28, 2024
Update cargo

19 commits in eaee77dc1584be45949b75e4c4c9a841605e3a4b..80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a
2024-09-19 21:10:23 +0000 to 2024-09-27 17:56:01 +0000
- Update cc to 1.1.22 (rust-lang/cargo#14607)
- feat: lockfile path implies --locked on cargo install (rust-lang/cargo#14556)
- feat(toml): Add `autolib` (rust-lang/cargo#14591)
- fix: correct error count for `cargo check --message-format json` (rust-lang/cargo#14598)
- test: relax panic output assertion (rust-lang/cargo#14602)
- feat(timings): support dark color scheme in HTML output (rust-lang/cargo#14588)
- feat: add CARGO_MANIFEST_PATH env variable (rust-lang/cargo#14404)
- fix(config): Don't double-warn about `$CARGO_HOME/config` (rust-lang/cargo#14579)
- fix(cargo-rustc): give trailing flags higher precedence on nightly (rust-lang/cargo#14587)
- feat: make lockfile v4 the default (rust-lang/cargo#14595)
- perf: Improve quality of completion performance traces (rust-lang/cargo#14592)
- test: Remove completion tests (rust-lang/cargo#14590)
- feat: Add support for completing `cargo update &lt;TAB&gt;` (rust-lang/cargo#14552)
- test: Migrate remaining with_stdout/with_stderr calls (rust-lang/cargo#14577)
- fix(resolve): Improve multi-MSRV workspaces (rust-lang/cargo#14569)
- chore: Bump MSRV to 1.81 (rust-lang/cargo#14585)
- Add a `--dry-run` flag to the `install` command (rust-lang/cargo#14280)
- fix(resolve): Don't list transitive, incompatible dependencies as available (rust-lang/cargo#14568)
- feat(complete): Upgrade clap_complete (rust-lang/cargo#14573)
@rustbot rustbot added this to the 1.83.0 milestone Sep 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-execution Area: anything dealing with executing the compiler S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent summary on error count with --message-format=json
6 participants