rustdoc-json: Invalid output for function returning public item from private module

[aDotInTheVoid]

#![feature(no_core)]
#![no_core]
mod secret {
    pub struct Secret;
}

pub fn get_secret() -> secret::Secret {
    secret::Secret
}

Produces (redacted for clairty, full here)

{
    "includes_private": false,
    "index": {
        "0:0": {
            "id": "0:0",
            "inner": {
                "is_crate": true,
                "items": [
                    "0:4"
                ]
            },
            "kind": "module",
            "name": "hashbrown",
            "visibility": "public"
        },
        "0:4": {
            "id": "0:4",
            "inner": {
                "decl": {
                    "inputs": [],
                    "output": {
                        "inner": {
                            "id": "0:2",
                            "name": "secret::Secret"
                        },
                        "kind": "resolved_path"
                    }
                }
            },
            "kind": "function",
            "name": "get_secret",
            "visibility": "public"
        }
    },
    "root": "0:0"
}

Where 0:2 is a dangling Id.

This fails check_missing_items.py with output Type contained an invalid ID: 0:2

IMO the best way would be to include these "Hidden" items, as the items they have can still be called, even if their is no publicly visable way to write their type.
(eg)

This would also improve the HTML, which currently doesnt give links to such items. However it's unclear how to document such an item that doesn't appear in a path.

cc @CraftSpider

@rustbot modify labels: +T-rustdoc +A-rustdoc-json

[CraftSpider]

This is basically the same as the other issues which led to me opening my current PR that proposes not stripping modules in rustdoc-json. I need to fix the current issues with that branch at some point, and it should fix this as it will prevent there every being dangling items.

[aDotInTheVoid]

What is #93518 blocked on? I can't tell from the comments.

[GuillaumeGomez]

#93518 as is doesn't solve this issue. I'm currently working on it.