fix(ops): correct error messages for cargo fix --broken-code by raushan728 · Pull Request #16681 · rust-lang/cargo

raushan728 · 2026-02-28T12:43:22Z

When cargo fix applies suggestions but the code
still fails to compile, the error message was
misleading. This PR corrects the warning wording
and updates the relevant tests.

rustbot · 2026-02-28T12:43:27Z

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

raushan728 · 2026-02-28T14:45:30Z

r? epage

epage · 2026-02-28T19:24:18Z

A couple of quick notes

the issue is marked S-needs-design
this is set to close the issue but it had two parts under the assumption that they would be fixed together
writing directly to stderr is rare and we need to consider whether this fits
the wording feels off and doesn't conform to our diagnostic style guide

raushan728 · 2026-03-01T05:19:22Z

thanks for the review @epage
a few clarification:

Regarding s-needs-design — i was not sure about the expected design upfront. could u point me to what the agreed design should look like, or share any prior discussion? i will align my implementation accordingly
for the two-part issue — i focused on the --broken-code case (example 1). should example 2 also be addressed in this PR, or as a separate one?
for the stderr writing approch — is there a preferred way to emit this kind of msg in cargo'a diagnostic system? happy to refactor if there is a better pattern.
for the wording — could u share the diagnostic style guide or point to an example msg that follows it? i will update the text to match.

Happy to iterate on this!

epage · 2026-03-02T20:11:41Z

Regarding s-needs-design — i was not sure about the expected design upfront. could u point me to what the agreed design should look like, or share any prior discussion? i will align my implementation accordingly

Thats the intention of that label: it needs that design work done.

for the two-part issue — i focused on the --broken-code case (example 1). should example 2 also be addressed in this PR, or as a separate one?

I'm less concerned about the number of PRs and more about this closing the Issue without fully resolving it

for the stderr writing approch — is there a preferred way to emit this kind of msg in cargo'a diagnostic system? happy to refactor if there is a better pattern.

shell notes, warns, etc

for the wording — could u share the diagnostic style guide or point to an example msg that follows it? i will update the text to match.

See our contrib docs: https://doc.crates.io/contrib/implementation/console.html

raushan728 · 2026-03-03T16:10:42Z

thanks for docs @epage
my plan to fix both problems:

replace writeln!(stderr) with shell.warn() to follow cargo's output conventions
fix the msg fot both cases:
- when --broken-code is already used -> explain code was saved but is broken
- when --broken-code is not used -> suggest trying --broken-code
keep wording lowercase and brief as par style guide

this should fully resolve both example from the issue. will push update soon!

raushan728 · 2026-03-04T06:43:39Z

ready for re-review @epage

epage · 2026-03-05T16:21:27Z

I realized there were some misunderstandings on both our parts on this code and am working through some prep PRs to help straighten that out

epage · 2026-03-05T16:23:46Z

tests/testsuite/fix_n_times.rs

-Note that you may be able to make some more progress in the near-term
-fixing code with the `--broken-code` flag
-
+[WARNING] could not apply fixes; the code is already in a broken state. consider using `--broken-code` to save partial progress


This error does not look like the case in Example 2. Are we sure we have the right situation?

Are we no longer addressing Example 2?

epage · 2026-03-05T16:29:30Z

src/cargo/util/diagnostic_server.rs

+                    self.gctx.shell().warn(
+                        "could not apply fixes; the code is already in a \
+                         broken state. broken code was saved as requested \
+                         with `--broken-code`",
+                    )?;


I don't think this message is accurate. It looks like the fixes are applied but we want to report that it still fails

### What does this PR try to resolve? Instead of printing a warning as a - a warning - many individual blocks of text this switches us to print it all as a single warning. This will make it easier to adapt to annotate-snippets in the future (work is in progress). This was noticed while reviewing #16681 which led us down the wrong path there. ### How to test and review this PR?

raushan728 · 2026-03-06T05:43:18Z

Hey @epage, conflict resolved i have also updated the warning message wording and fixed the fix_n_times test assertions based on your feedback

(Note: The current CI failures seem to be unrelated nightly script breakages)

epage · 2026-03-06T15:52:16Z

Hey @epage, conflict resolved i have also updated the warning message wording and fixed the fix_n_times test assertions based on your feedback

A review was requested my I don't think my comments were addressed

epage · 2026-03-06T22:03:39Z

#16711 is now merged and it is safe to rebase

rustbot · 2026-03-07T10:24:56Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

raushan728 · 2026-03-18T14:34:58Z

@epage I respect your time, but could you please take a look at this once

epage · 2026-03-18T15:09:47Z

I have questions above that have not been addressed.

raushan728 · 2026-03-18T15:47:51Z

I have questions above that have not been addressed.

Sorry, I didn't get it.

updated message: "fixes were applied but the code
still does not compile; partially-fixed code was
saved due to --broken-code"
Example 2 is also addressed — broken_code_no_suggestions
in fix_n_times.rs now covers the case where code is
broken with no suggestions, via condition fix in mod.rs:
if fixes.files.is_empty() && !allow_broken_code

epage · 2026-03-18T19:19:07Z

tests/testsuite/fix.rs

+        .with_stderr_contains("[ERROR] errors present after applying fixes to crate `foo`")
+        .with_stderr_contains("[WARNING] fixes were applied but the code still does not compile; partially-fixed code was saved due to `--broken-code`")
+        .with_stderr_contains("[NOTE] original diagnostics will follow:")
+        .with_stderr_contains("[..]= cause: error[E0308]: mismatched types[..]")


Why were these changed from snapshots to contains?

See https://docs.rs/cargo-test-support/latest/cargo_test_support/struct.Execs.html#method.with_stderr_contains

epage · 2026-03-18T19:20:23Z

src/cargo/util/diagnostic_server.rs

                };

-                let report = &[
+                let issue_link = get_bug_report_url(self.workspace_wrapper);


Why was this line moved?

Unnecessary changes create noise in browsing diffs, making it harder to infer intent. When there are non-functional changes, prefer moving them to a refactor commit

epage · 2026-03-18T19:23:21Z

src/cargo/ops/fix/mod.rs

-    // FIXME: The error message here is not correct with --broken-code.
-    //        https://github.com/rust-lang/cargo/issues/10955
-    if fixes.files.is_empty() {
+    if fixes.files.is_empty() && !allow_broken_code {


Multiple changes are being done at once in this commit. Please split up individual changes to better describe in their commit their intent and to make it clearer by more incremental test updates.

epage · 2026-03-18T19:41:09Z

I have questions above that have not been addressed.

Sorry, I didn't get it.

1. updated message: "fixes were applied but the code
   still does not compile; partially-fixed code was
   saved due to `--broken-code`"

2. Example 2 is also addressed — `broken_code_no_suggestions`
   in `fix_n_times.rs` now covers the case where code is
   broken with no suggestions, via condition fix in `mod.rs`:
   `if fixes.files.is_empty() && !allow_broken_code`

In #16681 (comment), I asked a question and got no response. Code changes were made but it is unclear how they are in response to my questions. Looking at broken_code_no_suggestions, it is saying fixes were applied but no suggestions are present.

rustbot added Command-fix S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 28, 2026

rustbot assigned ehuss Feb 28, 2026

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from 3973cf9 to 68ced81 Compare February 28, 2026 13:58

rustbot assigned epage and unassigned ehuss Feb 28, 2026

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from 68ced81 to 8c3c403 Compare March 4, 2026 05:39

raushan728 changed the title ~~Fix poor error message when cargo fix --broken-code fails~~ fix(ops): correct error messages for cargo fix --broken-code Mar 4, 2026

epage mentioned this pull request Mar 4, 2026

refactor(fix): Prep for annotate-snippets #16702

Merged

epage reviewed Mar 5, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from bcf4239 to dffe9cf Compare March 6, 2026 05:22

This comment has been minimized.

Sign in to view

raushan728 requested a review from epage March 6, 2026 05:43

This comment has been minimized.

Sign in to view

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from dffe9cf to 23ac6a1 Compare March 7, 2026 10:24

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from 23ac6a1 to a1e21c0 Compare March 18, 2026 13:43

fix(ops): correct error messages for cargo fix --broken-code

fcde359

raushan728 force-pushed the fix/cargo-fix-broken-code-message branch from a1e21c0 to fcde359 Compare March 18, 2026 14:28

epage reviewed Mar 18, 2026

View reviewed changes

Conversation

raushan728 commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 28, 2026

Uh oh!

raushan728 commented Feb 28, 2026

Uh oh!

epage commented Feb 28, 2026

Uh oh!

raushan728 commented Mar 1, 2026

Uh oh!

epage commented Mar 2, 2026

Uh oh!

raushan728 commented Mar 3, 2026

Uh oh!

raushan728 commented Mar 4, 2026

Uh oh!

epage commented Mar 5, 2026

Uh oh!

epage Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

epage Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

epage Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

raushan728 commented Mar 6, 2026

Uh oh!

epage commented Mar 6, 2026

Uh oh!

This comment has been minimized.

epage commented Mar 6, 2026

Uh oh!

rustbot commented Mar 7, 2026

Uh oh!

raushan728 commented Mar 18, 2026

Uh oh!

epage commented Mar 18, 2026

Uh oh!

raushan728 commented Mar 18, 2026

Uh oh!

epage Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

epage Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

epage Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

epage commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

raushan728 commented Feb 28, 2026 •

edited

Loading