cargo
cargo copied to clipboard
Breaking change to `json-render-diagnostics` target name in nightly
When compiling with --message-format=json-render-diagnostics
I expected to see this target.name
match the name in Cargo.tom
Instead, I see the snake_case
version of the name. This differs from stable.
This appears to impact all lib crate types, but not bin
crates.
Meta
rustc --version --verbose
:
rustc 1.80.0-nightly (9c9b56879 2024-05-05)
binary: rustc
commit-hash: 9c9b568792ef20d8459c745345dd3e79b7c7fa8c
commit-date: 2024-05-05
host: aarch64-apple-darwin
release: 1.80.0-nightly
LLVM version: 18.1.4
Example
Create the test project.
mkdir my-example
cargo init
Compile on stable and view the output:
$ cargo +stable build --message-format=json-render-diagnostics 2> /dev/null | jq .
{
"reason": "compiler-artifact",
"package_id": "path+file:///private/tmp/my-example#0.1.0",
"manifest_path": "/private/tmp/my-example/Cargo.toml",
"target": {
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "my-example",
"src_path": "/private/tmp/my-example/src/lib.rs",
"edition": "2021",
"doc": true,
"doctest": true,
"test": true
},
"profile": {
"opt_level": "0",
"debuginfo": 2,
"debug_assertions": true,
"overflow_checks": true,
"test": false
},
"features": [],
"filenames": [
"/private/tmp/my-example/target/debug/libmy_example.rlib",
"/private/tmp/my-example/target/debug/deps/libmy_example-cabcf031fa7095e7.rmeta"
],
"executable": null,
"fresh": false
}
{
"reason": "build-finished",
"success": true
}
Compile with nightly:
$ cargo +nightly build --message-format=json-render-diagnostics 2> /dev/null | jq .
{
"reason": "compiler-artifact",
"package_id": "path+file:///private/tmp/my-example#0.1.0",
"manifest_path": "/private/tmp/my-example/Cargo.toml",
"target": {
"kind": [
"lib"
],
"crate_types": [
"lib"
],
"name": "my_example",
"src_path": "/private/tmp/my-example/src/lib.rs",
"edition": "2021",
"doc": true,
"doctest": true,
"test": true
},
"profile": {
"opt_level": "0",
"debuginfo": 2,
"debug_assertions": true,
"overflow_checks": true,
"test": false
},
"features": [],
"filenames": [
"/private/tmp/my-example/target/debug/libmy_example.rlib",
"/private/tmp/my-example/target/debug/deps/libmy_example-f13fc0aeb358fb87.rmeta"
],
"executable": null,
"fresh": false
}
{
"reason": "build-finished",
"success": true
}
Note that on stable name
is my-example
, but on nightly, it is my_example
.
$ cargo +stable build --message-format=json-render-diagnostics 2> /dev/null | jq '.target.name'
"my-example"
null
$ cargo +nightly build --message-format=json-render-diagnostics 2> /dev/null | jq '.target.name'
"my_example"
null
The regression appeared in version nightly-2024-03-21
. Earlier versions do not exhibit the behavior.
https://github.com/rust-lang/cargo/commit/3ca04e261e1abde062b1c58a31a0ae622547d972 from https://github.com/rust-lang/cargo/pull/12783 seems related.
cc @weihanglo
Testing the changes, that does appear to be the cause. There has been some additional refactoring that prevents a clean revert.
Thanks for the report. Yes, that's #12783, which fixes the behavior to match the documentation. See https://github.com/rust-lang/cargo/pull/12783#issuecomment-1750726159. This is considered as a bugfix for the implementation. I've opened https://github.com/rust-lang/cargo/pull/13882 to include this caveat in the CHANGELOG.
Thanks for the quick response!
I understand that it was intentional, but I think it would make more sense to update the documentation.
The output of diagnostics is the only reliable way to find the generated artifacts (lots of flags can move the location).
This change broke the build system for a project I maintain and I suspect it will break others. For example, this is the method that Neon has used to find and copy the final cdylib
used for the last several years. It would require further investigation to get an exact number (command line flags, crate name), but it likely impacts a few hundred projects on github.
CC: @dherman
Here is a prior discussion of it. And I totally understand that. I'll check if we can make JSON message documentation a bit clearer. Thank you.