-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc-json: Refractor and document Id's #133981
Conversation
This comment has been minimized.
This comment has been minimized.
58a9e1d
to
e62b16f
Compare
This comment has been minimized.
This comment has been minimized.
e62b16f
to
324a73d
Compare
src/librustdoc/json/ids.rs
Outdated
pub(super) struct FullItemId { | ||
/// The "main" id of the item. | ||
/// | ||
/// In most cases this unequely identifies the item, other fields are just | ||
/// used for edge-cases. | ||
def_id: DefId, | ||
|
||
/// An extra [`DefId`], which we need for: | ||
/// | ||
/// 1. Auto-trait impls synthesized by rustdoc. | ||
/// 2. Blanket impls synthesized by rustdoc. | ||
/// 3. Splitting of reexports of multiple items. | ||
/// | ||
/// Eg: | ||
/// | ||
/// ```rust | ||
/// mod module { | ||
/// pub struct Foo {} // Exists in type namespace | ||
/// pub fn Foo(){} // Exists in value namespace | ||
/// } | ||
/// | ||
/// pub use module::Foo; // Imports both items | ||
/// ``` | ||
/// | ||
/// In HIR, the `pub use` is just 1 item, but in rustdoc-json it's 2, so | ||
/// we need to disambiguate. | ||
extra_id: Option<DefId>, | ||
|
||
/// Needed for `rustc_doc_primitive` modules. | ||
/// | ||
/// For these, 1 [`DefId`] is used for both the primitive and the fake-module | ||
/// that holds it's docs. | ||
/// | ||
/// N.B. This only matters when documenting the standard library with | ||
/// `--document-private-items`. Maybe we should delete that module, and | ||
/// remove this. | ||
name: Option<Symbol>, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this struct be an enum? I'd expect the fields extra_id
& name
to never be Some
simultaneously
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, do we need to store the name? if this only exists to generate 2 rustdoc IDs for what is 1 ID in rustc, this field could be a boolean, say, is_primitive
, or just an enum variant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could do that, and end up with something like clean::ItemId
again.
Now I'm almost curious if we could use clean::ItemId
in place of json::ids::FullItemId
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not, FullItemId
would also need a Primitive
variant then, along with the variants of ItemId
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's best to leave that to a followup then. The structure's already sufficiently different.
☔ The latest upstream changes (presumably #134381) made this pull request unmergeable. Please resolve the merge conflicts. |
324a73d
to
70e22b3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very sorry that this took so long, this shouldn't happen in the future! The changes look good.
r=me with nitpicks addressed and squashed into ~1 commit (the SingleItemId
excursion needn't be in the final history :)).
src/librustdoc/json/ids.rs
Outdated
/// One of these coresponds to every: | ||
/// 1. [`rustdoc_json_types::Item`]. | ||
/// 2. [`rustdoc_json_types::Id`] transitivly (as each `Item` has an `Id`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rephrase it like "Each one corresponds to an:" because "one […] corresp. to every" sounds like a one-to-many relation to me (but I'm L2) while this is is a one-to-one-to-one relation, right?
src/librustdoc/json/ids.rs
Outdated
/// mod module { | ||
/// pub struct Foo {} // Exists in type namespace | ||
/// pub fn Foo(){} // Exists in value namespace | ||
/// } | ||
/// | ||
/// pub use module::Foo; // Imports both items | ||
/// ``` | ||
/// | ||
/// In HIR, the `pub use` is just 1 item, but in rustdoc-json it's 2, so | ||
/// we need to disambiguate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These lines are intended by one extra space (this actually shows up literally in the rendered code block)
src/librustdoc/json/ids.rs
Outdated
let (def_id, mut extra_id) = match item_id { | ||
clean::ItemId::DefId(did) => (did, None), | ||
clean::ItemId::Blanket { for_, impl_id } => (for_, Some(impl_id)), | ||
clean::ItemId::Auto { for_, trait_ } => (for_, Some(trait_)), | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you wrote it like this:
let (def_id, mut extra_id) = match item_id { | |
clean::ItemId::DefId(did) => (did, None), | |
clean::ItemId::Blanket { for_, impl_id } => (for_, Some(impl_id)), | |
clean::ItemId::Auto { for_, trait_ } => (for_, Some(trait_)), | |
}; | |
let (def_id, extra_id) = match item_id { | |
clean::ItemId::DefId(did) => (did, imported_id), | |
clean::ItemId::Blanket { for_, impl_id } => (for_, Some(impl_id)), | |
clean::ItemId::Auto { for_, trait_ } => (for_, Some(trait_)), | |
}; |
src/librustdoc/json/ids.rs
Outdated
|
||
if let Some(imported_id) = imported_id { | ||
assert_eq!(extra_id, None, "On an import item, so won't have extra from impl"); | ||
extra_id = Some(imported_id); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...then you could remove this entirely, right?
if let Some(imported_id) = imported_id { | |
assert_eq!(extra_id, None, "On an import item, so won't have extra from impl"); | |
extra_id = Some(imported_id); | |
} |
35add17
to
5f510a3
Compare
I want to work on this in a followup commit, so in this commit I make it self-contained. Contains no code changes, all functions are defined exactly as they were in conversions.rs.
5f510a3
to
2e1d3d1
Compare
@bors r=fmease |
This comment has been minimized.
This comment has been minimized.
Alot of the current id handling is weird and unnecessary. e.g: 1. The fully uninterned id type was (FullItemId, Option<FullItemId>) meaning it wasn't actually full! 2. None of the extra fields in Option<FullItemId> would ever be used 3. imported_item_id was a rustdoc_json_types::Id instead of a simpler DefId This commit removes the unnessessary complexity, and documents where the remaining complexity comes from. Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2e1d3d1
to
a05d6ab
Compare
@bors r=fmease |
…=fmease rustdoc-json: Refractor and document Id's Closes rust-lang#133780 While working on documenting Id's, I realized alot of the way they were generated was weird and unnecessary. Eg: 1. The fully uninterned id type was `(FullItemId, Option<FullItemId>)`, meaning it wasn't actually full! 2. None of the extra fields in `Option<FullItemId>` would ever be used 3. `imported_item_id` was a `rustdoc_json_types::Id` instead of a simpler `DefId`. I believe the new implementation still covers all the same cases, but in a more principled way (and explaining why each piece is needed). This was written to be reviewed commit-by-commit, but it might be easier to review all at once if you're not interested in tracking how the original code became the final code. cc `@its-the-shrimp` r? `@fmease`
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#126856 (remove deprecated tool `rls`) - rust-lang#133981 (rustdoc-json: Refractor and document Id's) - rust-lang#136842 (Add libstd support for Trusty targets) - rust-lang#137355 (Implement `read_buf` and vectored read/write for SGX stdio) - rust-lang#137457 (fix for issue 132802: x86 code in `wasm32-unknown-unknown` binaries) - rust-lang#138162 (Update the standard library to Rust 2024) - rust-lang#138273 (metadata: Ignore sysroot when doing the manual native lib search in rustc) - rust-lang#138346 (naked functions: on windows emit `.endef` without the symbol name) - rust-lang#138370 (Simulate OOM for the `try_oom_error` test) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#126856 (remove deprecated tool `rls`) - rust-lang#133981 (rustdoc-json: Refractor and document Id's) - rust-lang#136842 (Add libstd support for Trusty targets) - rust-lang#137355 (Implement `read_buf` and vectored read/write for SGX stdio) - rust-lang#138162 (Update the standard library to Rust 2024) - rust-lang#138273 (metadata: Ignore sysroot when doing the manual native lib search in rustc) - rust-lang#138346 (naked functions: on windows emit `.endef` without the symbol name) - rust-lang#138370 (Simulate OOM for the `try_oom_error` test) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133981 - aDotInTheVoid:document-docs-ids, r=fmease rustdoc-json: Refractor and document Id's Closes rust-lang#133780 While working on documenting Id's, I realized alot of the way they were generated was weird and unnecessary. Eg: 1. The fully uninterned id type was `(FullItemId, Option<FullItemId>)`, meaning it wasn't actually full! 2. None of the extra fields in `Option<FullItemId>` would ever be used 3. `imported_item_id` was a `rustdoc_json_types::Id` instead of a simpler `DefId`. I believe the new implementation still covers all the same cases, but in a more principled way (and explaining why each piece is needed). This was written to be reviewed commit-by-commit, but it might be easier to review all at once if you're not interested in tracking how the original code became the final code. cc ``@its-the-shrimp`` r? ``@fmease``
Closes #133780
While working on documenting Id's, I realized alot of the way they were generated was weird and unnecessary. Eg:
(FullItemId, Option<FullItemId>)
, meaning it wasn't actually full!Option<FullItemId>
would ever be usedimported_item_id
was arustdoc_json_types::Id
instead of a simplerDefId
.I believe the new implementation still covers all the same cases, but in a more principled way (and explaining why each piece is needed).
This was written to be reviewed commit-by-commit, but it might be easier to review all at once if you're not interested in tracking how the original code became the final code.
cc @its-the-shrimp
r? @fmease