Basically, it doesn't make sense to generate those things every time
you search. That generates a bunch of stuff for the GC to clean up,
when, if the user wanted to do another search, it would just need
to re-do it again.
Every time splice() is called, another temporary object is created.
This version, which uses plain objects as a sort of Hash Bag,
should only produce one temporary object each time it's called.
There is no reason for this function to return an object,
since it is always used for getting at the name anyhow.
It's used in the inner loop for some popular functions,
so we want to avoid allocating in it.
rustdoc: tweak the search index format
This essentially switches search-index.js from a "array of struct" to a "struct of array" format, like this:
{
"doc": "Crate documentation",
"t": [ 1, 1, 2, 3, ... ],
"n": [ "Something", "SomethingElse", "whatever", "do_stuff", ... ],
"q": [ "a::b", "", "", "", ... ],
"d": [ "A Struct That Does Something", "Another Struct", "a function", "another function", ... ],
"i": [ 0, 0, 1, 1, ... ],
"f": [ null, null, [], [], ... ],
"p": ...,
"a": ...
}
So `{ty: 1, name: "Something", path: "a::b", desc: "A Struct That Does Something", parent_idx: 0, search_type: null}` is the first item.
This makes the uncompressed version smaller, but it really shows on the compressed version:
notriddle:rust$ wc -c new-search-index1.52.0.js
2622427 new-search-index1.52.0.js
notriddle:rust$ wc -c old-search-index1.52.0.js
2725046 old-search-index1.52.0.js
notriddle:rust$ gzip new-search-index1.52.0.js
notriddle:rust$ gzip old-search-index1.52.0.js
notriddle:rust$ wc -c new-search-index1.52.0.js.gz
239385 new-search-index1.52.0.js.gz
notriddle:rust$ wc -c old-search-index1.52.0.js.gz
296328 old-search-index1.52.0.js.gz
That's a 4% improvement on the uncompressed version (fewer `[]`, and also changing `null` to `0` in the parent_idx list), and 20% improvement after gzipping it, thanks to putting like-typed data next to each other. Any compression algorithm based on a sliding window will probably show this kind of improvement.
This essentially switches search-index.js from a "array of struct"
to a "struct of array" format, like this:
{
"doc": "Crate documentation",
"t": [ 1, 1, 2, 3, ... ],
"n": [ "Something", "SomethingElse", "whatever", "do_stuff", ... ],
"q": [ "a::b", "", "", "", ... ],
"d": [ "A Struct That Does Something", "Another Struct", "a function", "another function", ... ],
"i": [ 0, 0, 1, 1, ... ],
"f": [ null, null, [], [], ... ],
"p": ...,
"a": ...
}
So `{ty: 1, name: "Something", path: "a::b", desc: "A Struct That Does Something", parent_idx: 0, search_type: null}` is the first item.
This makes the uncompressed version smaller, but it really shows on the
compressed version:
notriddle:rust$ wc -c new-search-index1.52.0.js
2622427 new-search-index1.52.0.js
notriddle:rust$ wc -c old-search-index1.52.0.js
2725046 old-search-index1.52.0.js
notriddle:rust$ gzip new-search-index1.52.0.js
notriddle:rust$ gzip old-search-index1.52.0.js
notriddle:rust$ wc -c new-search-index1.52.0.js.gz
239385 new-search-index1.52.0.js.gz
notriddle:rust$ wc -c old-search-index1.52.0.js.gz
296328 old-search-index1.52.0.js.gz
notriddle:rust$
That's a 4% improvement on the uncompressed version (fewer `[]`),
and 20% improvement after gzipping it, thanks to putting like-typed
data next to each other. Any compression algorithm based on a sliding
window will probably show this kind of improvement.
Remove `masked_crates` from `clean::Crate`
Previously, `masked_crates` existed both on `Cache` and on
`clean::Crate`. During cache population, the `clean::Crate` version was
`take`n and moved to `Cache`.
This change removes the version on `clean::Crate` and instead directly
mutates `Cache.masked_crates` to initialize it. This has the advantage
of avoiding duplication and avoiding unnecessary allocation, as well as
making the flow of information through rustdoc less confusing.
The one downside I see is that `clean::utils::krate()` now uses the side
effect of mutating `DocContext.cache` instead of returning the data
directly, but it already mutated the `Cache` for other things (e.g.,
`deref_trait_did`) so it's not really new behavior. Also,
`clean::utils::krate()` is only called once (and is meant to only be
called once since it performs expensive and potentially destructive
operations) so the mutation shouldn't be an issue.
Follow-up to https://github.com/rust-lang/rust/pull/82018#discussion_r584197747.
cc `@jyn514`
Treat header as first paragraph for shortened markdown descriptions
"The Rust Standard LibraryThe Rust Standard Library is the …" is an awful description.
rustdoc: Remove redundant enableSearchInput function
enableSearchInput was called from two places:
- setupSearchLoader
- addSearchOptions, which is itself called from setupSearchLoader only
This commit can safely get rid of the addSearchOptions calls entirely, and since the setupSearchLoader call is immediately preceded by other method calls on search_input, there's no need to check if it's set.
Store HIR attributes in a side table
Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.
Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.
Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.
~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~
Previously, `masked_crates` existed both on `Cache` and on
`clean::Crate`. During cache population, the `clean::Crate` version was
`take`n and moved to `Cache`.
This change removes the version on `clean::Crate` and instead directly
mutates `Cache.masked_crates` to initialize it. This has the advantage
of avoiding duplication and avoiding unnecessary allocation, as well as
making the flow of information through rustdoc less confusing.
The one downside I see is that `clean::utils::krate()` now uses the side
effect of mutating `DocContext.cache` instead of returning the data
directly, but it already mutated the `Cache` for other things (e.g.,
`deref_trait_did`) so it's not really new behavior. Also,
`clean::utils::krate()` is only called once (and is meant to only be
called once since it performs expensive and potentially destructive
operations) so the mutation shouldn't be an issue.
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
rustdoc: Cleanup `html::render::Context`
- Move most shared fields to `SharedContext` (except for `cache`, which
isn't mutated anyway)
- Replace a use of `Arc` with `Rc`
- Make a bunch of fields private
- Add static size assertion for `Context`
- Don't share `id_map` and `deref_id_map`
Update minifier dependency version
Very small PR simply upgrading the minifier-rs version we use in rustdoc.
Some details might be useful: there were a few bug fixes and a lot of cleanup/code improvements.
r? `@camelid`
Remove Item::kind, use tagged enum. Rename variants to match
Fixes#82299, by making the ItemEnum tagged. Doesn't remove ItemKind as it's still used in other places.
r? `````@jyn514`````
`````@rustbot````` label: +A-rustdoc-json +T-rustdoc
rustdoc: Add an unstable option to print all unversioned files
This allows sharing those files between different doc invocations
without having to know their names ahead of time.
Helps with https://github.com/rust-lang/docs.rs/issues/1302.
r? ````@GuillaumeGomez```` cc ````@pietroalbini```` ````@Nemo157````
Cleanup rustdoc warnings
## Clean up error reporting for deprecated passes
Using `error!` here goes all the way back to the original commit, https://github.com/rust-lang/rust/pull/8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See https://github.com/rust-lang/rust/pull/81932#issuecomment-785291244 for further context.
- Use spans for deprecated attributes
- Use a proper diagnostic for unknown passes, instead of error logging
- Add tests for unknown passes
- Improve some wording in diagnostics
## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!`
This also adds a test for the output.
This was added in https://github.com/rust-lang/rust/pull/52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in https://github.com/rust-lang/rust/pull/50541.
Remove RefCell around `module_trait_cache`
This builds on https://github.com/rust-lang/rust/pull/82018 and should not be merged before.
## Don't require a `DocContext` for `report_diagnostic`
This is needed for the next commit, which needs mutable access to the `cx` from
within the `decorate` closure.
- Change `as_local_hir_id` to an associated function, since it only
needs a `TyCtxt`
- Change `source_span_for_markdown_range` to only take a `TyCtxt`
## Remove RefCell around module_trait_cache
This is mostly just changing lots of functions from `&DocContext` to `&mut DocContext`.
Rust contains various size checks conditional on target_arch = "x86_64",
but these checks were never intended to apply to
x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the
conditions.
I don't think the boxing helped performance, in fact I think it
potentially made it worse. The data was still being copied, but now it
was through a pointer. Thinking about it more, I think boxing might only
help when you're passing a big object around by value all the time,
rather than the slowdown being that you're cloning it.
There was no need to clone `id_map` because it was reset before each
item was rendered. `deref_id_map` was not reset, but it was keyed by
`DefId` and thus was unlikely to have collisions (at least for now).
Now we just clone the fields that need to be cloned, and instead create
fresh versions of the others.
All the tests passed, so it doesn't seem they need to be shared.
Plus they should be item/page-specific.
I'm not sure why they were shared before. I think the reason `id_map`
worked as a shared value before is that it is cleared before rendering
each item (in `render_item`). And then I'm guessing `deref_id_map`
worked because it's a hashmap keyed by `DefId`, so there was no overlap
(though I'm guessing we could have had issues in the future).
Note that `id_map` currently still has to be cleared because otherwise
child items would inherit the `id_map` of their parent. I'm hoping to
figure out a way to stop cloning `Context`, but until then we have to
reset `id_map`.
It doesn't look like it's shared across threads, so it doesn't need to
be thread-safe. Of course, since we're using Rust, we'll get an error if
we try to share it across threads, so this should be safe :)
rustdoc: Use substrings instead of split to grab enum variant paths
Both versions are about equally readable, but this version avoids scanning the entire path and building an intermediate array (`split()` in Rust is a lazy iterator, but not in JavaScript).
Make ItemKind::ExternCrate looks like hir::ItemKind::ExternCrate to make transition over hir::ItemKind simpler
It was surprisingly difficult to make this change, mostly because of two issues:
* We now store the `ExternCrate` name in the parent struct (`clean::Item`), which forced me to modify the json conversion code a bit more than expected.
* The second problem was that, since we now have a `Some(name)`, it was trying to render it, ending up in a panic because we ended up in a `unreachable` statement. The solution was simply to add `!item.is_extern_crate()` in `formats::renderer` before calling `cx.item(item, &cache)?;`.
I'll continue to replace all the `clean::ItemKind` variants one by one until it looks exactly like `hir::ItemKind`. Then we'll simply discard the rustdoc type. Once this done, we'll be able to discard `clean::Item` too to use `hir::Item`.
r? ``@jyn514``
