Rustdoc JSON includes unexpected items from core and alloc

[obi1kenobi]

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an impl str block and its contents.

I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate.

Instead, this happened: the rustdoc JSON file contains items like this:

{
    "id": "2:12074",
    "crate_id": 2,
    "name": null,
    "span": null,
    "visibility": "default",
    "docs": null,
    "links": {},
    "attrs": [
        "#[cfg(not(test))]"
    ],
    "deprecation": null,
    "inner": {
        "impl": {
            "is_unsafe": false,
            "generics": {
                "params": [],
                "where_predicates": []
            },
            "provided_trait_methods": [],
            "trait": null,
            "for": {
                "primitive": "str"
            },
            "items": [
                "2:12075:816",
                "2:12076:23700",
                "2:12077:31130",
                "2:12078:31131",
                "2:12080:31132",
                "2:12083:20848",
                "2:12084:31133",
                "2:12085:314",
                "2:12086:24047",
                "2:12087:24043",
                "2:12089:24044",
                "2:12091:24045",
                "2:12093:24046",
                "2:12095:31134",
                "2:12096:31135",
                "2:12097:24069",
                "2:12098:24070",
                "2:12099:28134",
                "2:12100:28060",
                "2:12101:19933",
                "2:12102:28095",
                "2:12103:28078",
                "2:12104:19683",
                "2:12105:31136",
                "2:12106:28135",
                "2:12107:24086",
                "2:12110:24087",
                "2:12113:24088",
                "2:12116:19622",
                "2:12120:19623",
                "2:12124:19682",
                "2:12127:24078",
                "2:12130:24080",
                "2:12133:31137",
                "2:12136:31138",
                "2:12139:24082",
                "2:12142:24084",
                "2:12145:31139",
                "2:12148:31140",
                "2:12151:1866",
                "2:12154:31141",
                "2:12157:31142",
                "2:12160:31143",
                "2:12163:31144",
                "2:12165:31145",
                "2:12167:31146",
                "2:12169:31147",
                "2:12170:31148",
                "2:12171:31149",
                "2:12174:31150",
                "2:12177:20053",
                "2:12180:24089",
                "2:12183:31151",
                "2:12186:31152",
                "2:12189:31153",
                "2:12192:31154",
                "2:12194:23164",
                "2:12195:23856",
                "2:12196:23168",
                "2:12197:23169",
                "2:12198:23170",
                "2:12199:31155",
                "2:12201:1975",
                "2:12202:31156"
            ],
            "negative": false,
            "synthetic": false,
            "blanket_impl": null
        }
    }
}

In this example, crate_id: 2 is core and here are the names of the items contained in that impl (also part of the rustdoc JSON):

[
  "as_ptr",
  "parse",
  "strip_suffix",
  "is_ascii",
  "starts_with",
  "provide",
  "trim_end_matches",
  "split_ascii_whitespace",
  "try_from",
  "escape_default",
  "ceil_char_boundary",
  "as_bytes_mut",
  "get_mut",
  "matches",
  "char_indices",
  "into",
  "try_into",
  "slice_unchecked",
  "trim",
  "make_ascii_uppercase",
  "trim_start_matches",
  "trim_left_matches",
  "floor_char_boundary",
  "rsplit",
  "split_at_mut",
  "encode_utf16",
  "lines",
  "escape_unicode",
  "as_ascii",
  "lines_any",
  "split",
  "trim_end",
  "chars",
  "get",
  "split_at",
  "type_id",
  "as_bytes",
  "rmatches",
  "rsplit_once",
  "split_whitespace",
  "trim_right_matches",
  "split_inclusive",
  "trim_right",
  "eq_ignore_ascii_case",
  "get_unchecked",
  "trim_start",
  "get_unchecked_mut",
  "is_empty",
  "borrow_mut",
  "make_ascii_lowercase",
  "is_char_boundary",
  "from",
  "from",
  "strip_prefix",
  "find",
  "split_terminator",
  "match_indices",
  "into_iter",
  "as_mut_ptr",
  "trim_matches",
  "rsplitn",
  "contains",
  "split_once",
  "escape_debug",
  "rmatch_indices",
  "trim_left",
  "splitn",
  "rsplit_terminator",
  "bytes",
  "len",
  "ends_with",
  "borrow",
  "slice_mut_unchecked",
  "rfind"
]

Similarly, you can find items from alloc: Trustfall playground

Invocation for generating rustdoc JSON:

cargo +nightly rustdoc --package <crate_name> --all-features -- --document-private-items -Zunstable-options --output-format json

Meta

rustc --version --verbose:

rustc 1.73.0-nightly (8771282d4 2023-07-23)
binary: rustc
commit-hash: 8771282d4e7a5c4569e49d1f878fb3ba90a974d0
commit-date: 2023-07-23
host: x86_64-unknown-linux-gnu
release: 1.73.0-nightly
LLVM version: 16.0.5

You can find a variety of pre-generated rustdoc JSON files with this issue here: https://github.com/obi1kenobi/crates-rustdoc/tree/main/rustdoc-v26/max-version

Briefly discussed in Zulip: https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Rustdoc.20JSON.3A.20Unexpected.20.60core.60.20items.20included.20in.20output

I'll have to work around this behavior to shield cargo-semver-checks, which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown.

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

[aDotInTheVoid]

Possibly duplicate of #101201

[obi1kenobi]

Might be! Definitely at least some overlap, not entirely sure if duplicate.

Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?

[aDotInTheVoid]

Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.