cargo icon indicating copy to clipboard operation
cargo copied to clipboard

Breaking change to `json-render-diagnostics` target name in nightly

Open kjvalencik opened this issue 9 months ago • 3 comments

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

kjvalencik avatar May 06 '24 15:05 kjvalencik

The regression appeared in version nightly-2024-03-21. Earlier versions do not exhibit the behavior.

kjvalencik avatar May 06 '24 16:05 kjvalencik

https://github.com/rust-lang/cargo/commit/3ca04e261e1abde062b1c58a31a0ae622547d972 from https://github.com/rust-lang/cargo/pull/12783 seems related.

cc @weihanglo

Urgau avatar May 06 '24 17:05 Urgau

Testing the changes, that does appear to be the cause. There has been some additional refactoring that prevents a clean revert.

kjvalencik avatar May 06 '24 17:05 kjvalencik

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.

weihanglo avatar May 08 '24 04:05 weihanglo

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

kjvalencik avatar May 08 '24 12:05 kjvalencik

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.

weihanglo avatar May 08 '24 15:05 weihanglo