-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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: change item ID's repr from a string to an int #130078
rustdoc-json: change item ID's repr from a string to an int #130078
Conversation
rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi Some changes occurred in src/librustdoc/clean/types.rs cc @camelid |
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 broadly speaking quite unfamiliar with the librustdoc portion of the codebase, so apologies for my ignorant questions here.
// FIXME(aDotInTheVoid): Consider making this non-public in rustdoc-types. | ||
pub struct Id(pub String); | ||
pub struct Id(pub u32); |
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.
Is there a way to recover the string ID from the numeric ID given a rustdoc JSON file? Or are you confident that isn't a capability that would be useful in any use case, so it isn't necessary to add?
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 do you mean "recover the string ID"? If you want to find what the Id would have been under the old schem, then no, this won't be possible, but I'm fine with that.
This comment has been minimized.
This comment has been minimized.
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.
This PR's doing alot, and needs major rework, so I've only tried to review it at a high level, as I don't think the in-the-weeds stuff is worth it yet.
- The changes to
ItemId
are intrusive to most of the rustdoc codebase, and not motivated at all. If these are nessessary, could that be explained, and send in a different, tighter-scoped, PR (that would be landed before this) - Making
Cache
be the only source of state for theclean
->json
lowering is quite a bad idea:- It requires adding a
TyCtxt
, which produces more changes to the rest of rustdoc. - It adds the interner field which isn't used for HTML, but is still present, which is unfortunate.
- In present, it requires adding a
Lock
, but I don't think this is inherent.
- It requires adding a
- There seem to be unrelated cleanups (like the removal of
FormatRenderer::cache
). These are should be merged into rustdoc, but not here! Again, the answer is a smaller, seperate PR, that just does one thing, and will be much easier to review.
60b7fab
to
f32c35a
Compare
This comment has been minimized.
This comment has been minimized.
Some tests are failing to compile due to them expecting the id to be |
☔ The latest upstream changes (presumably #130133) made this pull request unmergeable. Please resolve the merge conflicts. |
10aae07
to
c8bf3ef
Compare
@rustbot ready This time the interner is restricted to the JsonRenderer, however I still couldn't get rid of the lock on the interner because of borrow checking errors |
It could be possible to get rid of it if we were to change the way |
Or I can do it in this PR, the change should be very minimal |
should the FORMAT_VERSION be bumped for this? |
Most likely yes, it is an API change ( |
The representation of IDs doesn't have any guarantees associated with it though, and rustdoc-types can get a new major version without incrementing FORMAT_VERSION |
FORMAT_VERSION is how one would choose which rustdoc-types major version to
use to deserialize a rustdoc JSON file. It would be a major issue for
example for cargo-semver-checks if the format number doesn't get bumped
here.
Existing precedent is to bump it any time ~anything about the format
changes. It's been bumped over much smaller changes in the past. I'd say go
ahead and bump it here as well.
…On Wed, Sep 11, 2024, 5:42 AM Tim Kurdov ***@***.***> wrote:
should the FORMAT_VERSION be bumped for this?
Most likely yes, it is an API change (rustdoc-types will be unable to
parse files with Id(u32)).
The representation of IDs doesn't have any guarantees associated with it
though, and rustdoc-types can get a new major version without incrementing
FORMAT_VERSION
—
Reply to this email directly, view it on GitHub
<#130078 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR5MSQB7MZAOCQVBPBZW6TZWAF6VAVCNFSM6AAAAABN2ESABOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBTGE2TGMJWGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
c8bf3ef
to
507bd42
Compare
Yeah, bumping the format version needs to happen whenever we do something that breaks deserialisation (and I don’t know any times it’s been done for other reasons, but would be interested).
Previously we guaranteed they were strings. |
☔ The latest upstream changes (presumably #130724) made this pull request unmergeable. Please resolve the merge conflicts. |
507bd42
to
1e30b5a
Compare
struct FullItemId { | ||
def_id: DefId, | ||
name: Option<Symbol>, | ||
/// Used to distinguish imports of different items with the same name |
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.
NIT: This comment could be more useful. The problem it's actually trying to solve is that a single pub use
with 1 defid can expand to multiple rustdoc-json items it the name exists in multiple namespaces: https://godbolt.org/z/jEnGxoWx6.
At some point in the future, we should maybe change how we do this on the JSON side, but not in this PR.
@bors r+ Thanks for working on this, and sorry for the delay. |
…ess-ids, r=aDotInTheVoid rustdoc-json: change item ID's repr from a string to an int Following [this discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Optimizing.20the.20.60Id.60.20type.20in.20.60rustdoc-types.60), I've changed the repr of `rustdoc_json_types::Id` from a String to a u32, by adding a `clean::ItemId` interner to `JsonRenderer` r? `@aDotInTheVoid`
Rollup of 7 pull requests Successful merges: - rust-lang#130078 (rustdoc-json: change item ID's repr from a string to an int) - rust-lang#131065 (Port sort-research-rs test suite to Rust stdlib tests) - rust-lang#131109 (Stabilize `debug_more_non_exhaustive`) - rust-lang#131287 (stabilize const_result) - rust-lang#131463 (Stabilise `const_char_encode_utf8`.) - rust-lang#131543 (coverage: Remove code related to LLVM 17) - rust-lang#131552 (RustWrapper: adapt for rename of Intrinsic::getDeclaration) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#130078 - its-the-shrimp:rustdoc-types-compress-ids, r=aDotInTheVoid rustdoc-json: change item ID's repr from a string to an int Following [this discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Optimizing.20the.20.60Id.60.20type.20in.20.60rustdoc-types.60), I've changed the repr of `rustdoc_json_types::Id` from a String to a u32, by adding a `clean::ItemId` interner to `JsonRenderer` r? ``@aDotInTheVoid``
Following this discussion on Zulip, I've changed the repr of
rustdoc_json_types::Id
from a String to a u32, by adding aclean::ItemId
interner toJsonRenderer
r? @aDotInTheVoid