Attribute representation change in rustdoc JSON without version bump

[obi1kenobi]

Rustdoc JSON is a public but unstable API, whose contract is that behavior changes are signaled by incrementing its embedded version number.

Unfortunately, rustdoc JSON format v45 appears to have suffered a behavior change without a corresponding version bump. This was caught by the test suites of cargo-semver-checks and its components, which used to pass on the initial nightly version where format v45 was released but no longer pass:
https://github.com/obi1kenobi/trustfall-rustdoc-adapter/actions/runs/14585442486/job/41627682245

Output {
         instantiated_name: "Clone",
         attrs: [
-            "#[automatically_derived]",
+            "#[automatically_derived]\n",
         ],
         canonical_path: [
             "core",
             "clone",

in rustc 1.88.0-nightly (13e879094 2025-05-04)

At a glance, this may have been due to #140606. It may be sufficient to strip the trailing whitespace at the time rustdoc JSON is created to recover the original behavior.

[obi1kenobi]

@rustbot label +A-rustdoc-json +T-compiler

[aDotInTheVoid]

Short term, we can strip white space inside librustdoc, and get the old behaviour. I’ve got a patch locally that does this, I’ll make a PR once i describe it. It might still be worth bumping the format version, as v45 output might be buggy, but v46 output is good (even if v45 from before #140606 is the same as v45).

Longer term, I’d like to make this less likely to happen again. We should probably add a triage or message on changes to tests/rustdoc-json informing PR authors/reviewers to be careful as this is a public API, and that if they want to change it, the FORMAT_VERSION also needs to be bumped. Not sure exactly what would be most useful to say here. CC @nnethercote @dtolnay, what would have been useful to see when reviewing #140606?

[dtolnay]

It should get an autoreview like what we do for Cargo.lock: #140535 (comment)

Alona was pinged on the broken PR in #140606 (comment). But this comment is not enough for nnethercote or I to know what the review obligation is. Is there a bigger group to ping that would be more likely to intercept bad changes before landing? Some teams / working groups like clippy, miri, rust-analyzer, gcc, trait solver, and some other projects mention the team like this: #126893 (comment)

I would recommend trying with just a more explanatory autoreview comment and see whether it gets improperly ignored.

[obi1kenobi]

Not a rustdoc reviewer, but I'm happy to be pinged and participate if that's helpful — I've written parts of the rustdoc json test suite and I'm most likely to be downstream of breakage in it.