fix(cargo-wdk): use --message-format=json-render-diagnostics in the build command to render compiler errors instead of the plain json option

[svasista-ms]

Fixes #613

Problem

When cargo wdk build encounters a compilation error, the error output is hard to debug:

1. JSON wall — --message-format=json sends even the compiler diagnostics as JSON to stdout instead of redirecting it to stderr. So, compiler errors are not directly visible instead they are buried deep in the output json. This is affecting test outputs because in case of failures, the errors cannot be seen easily in the json output.
2. Redundant error content — BuildTaskError::CargoBuild wraps the full CommandError (containing stdout JSON), even though the user may have already seen the real compiler errors on stderr in real time.

Fixes

The following changes fix the above problems:

1. Switch to --message-format=json-render-diagnostics
   This option instructs cargo to render diagnostics from rustc directly to stderr instead of putting it in the json output.
   stdout: only machine-parseable JSON (artifacts, build-finished) — no diagnostic messages
   stderr: human-readable compiler errors and warnings, rendered by Cargo (visible to the user in real time since stderr is inherited)

2. Replace CommandError wrapping with a clean message:
   When cargo build fails, BuildTask::run() now maps the error to a simple "Compilation failed. See compiler errors above." string instead of forwarding the raw CommandError (which contained unhelpful JSON from stdout).

3. Change BuildTaskError::CargoBuild to hold String instead of CommandError
   Since we no longer need the structured error from the command, the variant now holds a descriptive String message.

Before

Running kmdf_driver_cross_compiles_with_cli_option_successfully test after removing aarch64-pc-windows-msvc target:

---

Compiler diagnostics not printed to stderr, instead it is buried in the json output when cargo wdk build fails:

---

Output seen when tests fail due to compilation errors:

After

Running kmdf_driver_cross_compiles_with_cli_option_successfully test after removing aarch64-pc-windows-msvc target:

---

Compiler diagnostics available on terminal:

---

Output seen when tests fail due to compilation errors:

[Copilot]

Pull request overview

Updates cargo-wdk’s build invocation and error handling so compiler diagnostics are shown to users/tests in a readable form (instead of being buried in JSON), addressing the debugging pain described in #613.

Changes:

• Switch cargo build to --message-format=json-render-diagnostics so diagnostics are rendered to stderr while keeping parseable JSON on stdout.
• Simplify BuildTaskError::CargoBuild to store a descriptive String message instead of the full CommandError.
• Update unit/integration tests to expect the new cargo argument and error shape.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
crates/cargo-wdk/src/actions/build/tests.rs	Updates expected cargo args in build-action tests to use the new message format.
crates/cargo-wdk/src/actions/build/error.rs	Changes BuildTaskError::CargoBuild payload from CommandError to String and updates its display format.
crates/cargo-wdk/src/actions/build/build_task.rs	Updates cargo args to json-render-diagnostics and maps command failures to a simplified compilation-failed message; adjusts unit tests accordingly.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

map_err(|_| ...) discards the underlying CommandError, so a cargo invocation failure (e.g., IoError when cargo isn’t found) will be reported as “Compilation failed”, which is misleading and makes debugging harder (especially since the CLI logs only Display). Consider matching on CommandError and producing a different message for IoError (including the io::Error), while keeping the simplified message for CommandFailed compilation errors.

Suggested change

	.map_err(|_| {
	BuildTaskError::CargoBuild("Compilation failed. See compiler errors above.".into())
	.map_err(|err| match err {
	crate::providers::exec::CommandError::IoError(err) => {
	BuildTaskError::CargoBuild(format!("Failed to invoke cargo build: {err}"))
	}
	crate::providers::exec::CommandError::CommandFailed(_) => {
	BuildTaskError::CargoBuild(
	"Compilation failed. See compiler errors above.".into(),
	)
	}

[gurry]

@svasista-ms This is important. We should return "Compilation failed" only in the case of a compilation error. We should return something else in all other cases as shown above by copilot.

Do have a test for cargo failures that are not due to compilation errors? If not then we should add them.

[Copilot]

Changing BuildTaskError::CargoBuild to hold only a String removes error chaining/source context from the original CommandError (notably the IoError case). If keeping the simplified user message for compile failures, consider adding a separate variant or optional #[source] field so non-compilation execution failures still surface actionable details.

[gurry]

Yes, we should not change it to string as we need to also support non-compilation-error failures (see the other comment).

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.46%. Comparing base (5748ea2) to head (7f61900).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #645      +/-   ##
==========================================
+ Coverage   78.44%   78.46%   +0.01%     
==========================================
  Files          25       25              
  Lines        5201     5196       -5     
  Branches     5201     5196       -5     
==========================================
- Hits         4080     4077       -3     
+ Misses       1001      999       -2     
  Partials      120      120              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.