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

[kjvalencik]

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]

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

[Urgau]

3ca04e2 from #12783 seems related.

cc @weihanglo

[kjvalencik]

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

[weihanglo]

Thanks for the report. Yes, that's #12783, which fixes the behavior to match the documentation. See #12783 (comment). This is considered as a bugfix for the implementation. I've opened #13882 to include this caveat in the CHANGELOG.

[kjvalencik]

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

[weihanglo]

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.