-
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
Get rid of clean
in rustdoc
#76382
Comments
RE |
I think not exposing a stable interface in some form is severely limiting the usefulness of having a decoupled backend in the first place, since then every third-party backend is reduced to the maintenance nightmare of a compiler plugin |
To be clear: this is the current situation. If you want rustdoc to have a stable, programmatic API that's a completely separate RFC. |
That said, I'm not inherently opposed to keeping |
Get rid of `clean::Deprecation` This brings the size of `item.deprecation` from 56 to 16 bytes. Helps with rust-lang#79103 and rust-lang#76382, in the same vein as rust-lang#79957. r? `@GuillaumeGomez`
First actually useful step in rust-lang#76382 This doesn't yet compile because there's no way to get a `Lrc<Session>` from a TyCtxt, only a `&Session`.
Pass a `TyCtxt` through to `FormatRender` This is the next step after rust-lang#79957 for rust-lang#76382. Eventually I plan to use this to remove `stability`, `const_stability`, and `deprecation` from `Item`, but that needs more extensive changes (in particular, rust-lang#75355 or something like it). This has no actual changes to behavior, it's just moving types around. ccc rust-lang#80014 (comment)
…meGomez [rustdoc] Calculate stability, const_stability, and deprecation on-demand Previously, they would always be calculated ahead of time, which bloated the size of `clean::Item`. Builds on rust-lang#80090 and should not be merged before. Helps with rust-lang#79103 and rust-lang#76382. cc rust-lang#80014 (comment) This brings `Item` down to 568 bytes, down from 616.
…umeGomez Remove `DefPath` from `Visibility` and calculate it on demand Depends on rust-lang#80090 and should not be merged before. Helps with rust-lang#79103 and rust-lang#76382. cc rust-lang#80014 (comment) - `@nnethercote` I figured it out! It was simpler than I expected :) This brings the size of `clean::Visibility` down from 40 bytes to 8. Note that this does *not* remove `clean::Visibility`, even though it's now basically the same as `ty::Visibility`, because the `Invsible` variant means something different from `Inherited` and I thought it would be be confusing to merge the two. See the new comments on `impl Clean for ty::Visibility` for details.
rustdoc: Remove most fields from ExternalCrate Once rust-lang#84304 is fixed, I can get rid of ExternCrate altogether in favor of CrateNum, but in the meantime, this shrinks ExternalCrate quite a lot. This might hurt compile-times; if it does, I can add `primitive` and `keyword` queries. I expect this to improve compilemem. Helps with rust-lang#76382. r? GuillaumeGomez
rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item, which avoids having to add more and more parameters. Helps with rust-lang#76382. r? `@camelid`
rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item, which avoids having to add more and more parameters. Helps with rust-lang#76382. r? ``@camelid``
rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item, which avoids having to add more and more parameters. Helps with rust-lang#76382. r? ```@camelid```
rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item, which avoids having to add more and more parameters. Helps with rust-lang#76382. r? ``@camelid``
rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item, which avoids having to add more and more parameters. Helps with rust-lang#76382. r? ```@camelid```
Calculate `span` info on-demand - Add helper `attr_span` for common reused function - Stop storing `Span`s on `Item` directly; calculate them on demand instead - Special case modules, which have different spans depending on whether you use inner or outer attributes - Special case impls with fake IDs, which can have either dummy spans (for auto traits) or the DefId of the impl block (for blanket impls) - Use a fake ID for primitives instead of the ID of the crate; this lets `source()` know that it should use a dummy span instead of the span of the crate. This shrinks `Item` from 48 to 40 bytes. Helps with rust-lang#76382.
rustdoc: Remove unnecessary `provided_trait_methods` field from Impl It can be calculated on-demand. Helps with rust-lang#76382.
…yn514 shrink doctree::Module helps rust-lang#76382
…yn514 shrink doctree::Module helps rust-lang#76382
…yn514 shrink doctree::Module helps rust-lang#76382
clean::Item
in rustdocclean
in rustdoc
I updated the title to reflect that we actually want to get rid of all of (or most of) |
I really don't think rustdoc should be trying to expose a stable interface at all. Rustdoc is already quite full with features, and this would significantly add to the already high maintenance burden. |
In practice I think the JSON backend is already serving that purpose. |
Currently, rustdoc has its own data structure for basically everything in the compiler:
librustdoc::clean::types
. Collecting these ahead of time is expensive (#74590 (comment)) and it would be better to instead calculate them on demand. This would reduce a ton of code duplication, speed up rustdoc, and hopefully fix bugs related to caching (#74879) and get rid of hacks like fake IDs (#75355).On the other hand, it's really hard.
The basic idea is to, instead of discarding the
TyCtxt
afterrun_core
, instead pass inTyCtxt
torender
. Thenrender
will calculate the info it needs as it comes up - possibly still with caching inDocContext
, but because this is on-demand it will be likecache.get().or_else(|| calculate_info())
, notcache.get().unwrap()
which is what leads to the bugs.cc @rust-lang/rustdoc - is this something you're interested in?
cc @RDambrosio016, @Kixiron - this would break your idea to have
librustdoc_render
be a separate crate fromlibrustdoc
, because there would inherently be no stable interface:DocContext
would be returning rustc types directly.cc @P1n3appl3 - this would require rewriting large parts of the JSON backend.
The text was updated successfully, but these errors were encountered: