Skip to content
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

Merged
merged 2 commits into from
Mar 13, 2025

Conversation

aDotInTheVoid
Copy link
Member

@aDotInTheVoid aDotInTheVoid commented Dec 6, 2024

Closes #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

@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Dec 6, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Comment on lines 29 to 66
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>,
}
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

@its-the-shrimp its-the-shrimp Dec 9, 2024

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

Copy link
Member Author

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.

@bors
Copy link
Contributor

bors commented Dec 17, 2024

☔ The latest upstream changes (presumably #134381) made this pull request unmergeable. Please resolve the merge conflicts.

@fmease fmease closed this Mar 12, 2025
@fmease fmease reopened this Mar 12, 2025
Copy link
Member

@fmease fmease left a 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 :)).

Comment on lines 22 to 24
/// One of these coresponds to every:
/// 1. [`rustdoc_json_types::Item`].
/// 2. [`rustdoc_json_types::Id`] transitivly (as each `Item` has an `Id`).
Copy link
Member

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?

Comment on lines 45 to 54
/// 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.
Copy link
Member

@fmease fmease Mar 12, 2025

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)

Comment on lines 79 to 83
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_)),
};
Copy link
Member

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:

Suggested change
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_)),
};

Comment on lines 103 to 107

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);
}
Copy link
Member

@fmease fmease Mar 12, 2025

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?

Suggested change
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);
}

@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 12, 2025
@rust-cloud-vms rust-cloud-vms bot force-pushed the document-docs-ids branch 2 times, most recently from 35add17 to 5f510a3 Compare March 12, 2025 21:33
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.
@rust-cloud-vms rust-cloud-vms bot force-pushed the document-docs-ids branch from 5f510a3 to 2e1d3d1 Compare March 12, 2025 21:39
@aDotInTheVoid
Copy link
Member Author

@bors r=fmease

@bors
Copy link
Contributor

bors commented Mar 12, 2025

📌 Commit 2e1d3d1 has been approved by fmease

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 12, 2025
@rust-log-analyzer

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>
@rust-cloud-vms rust-cloud-vms bot force-pushed the document-docs-ids branch from 2e1d3d1 to a05d6ab Compare March 12, 2025 22:10
@aDotInTheVoid
Copy link
Member Author

@bors r=fmease

@bors
Copy link
Contributor

bors commented Mar 12, 2025

📌 Commit a05d6ab has been approved by fmease

It is now in the queue for this repository.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 13, 2025
…=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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 13, 2025
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 13, 2025
…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
@bors bors merged commit b3ab695 into rust-lang:master Mar 13, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 13, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 13, 2025
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``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rustdoc-json: Document why Id can't just be DefId
6 participants