| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Helps with #90929
This changes the search results, specifically, when there's more than
one impl with an associated item with the same name. For example,
the search queries `simd<i8> -> simd<i8>` and `simd<i64> -> simd<i64>`
don't link to the same function, but most of the functions have the
same names.
This change should probably be FCP-ed, especially since it adds a new
anchor link format for `main.js` to handle, so that URLs like
`struct.Vec.html#impl-AsMut<[T]>-for-Vec<T,+A>/method.as_mut` redirect
to `struct.Vec.html#method.as_mut-2`. It's a strange design, but there
are a few reasons for it:
* I'd like to avoid making the HTML bigger. Obviously, fixing this bug
is going to add at least a little more data to the search index, but
adding more HTML penalises viewers for the benefit of searchers.
* Breaking `struct.Vec.html#method.len` would also be a disappointment.
On the other hand:
* The path-style anchors might be less prone to link rot than the numbered
anchors. It's definitely less likely to have URLs that appear to "work",
but silently point at the wrong thing.
* This commit arranges the path-style anchor to redirect to the numbered
anchor. Nothing stops rustdoc from doing the opposite, making path-style
anchors the default and redirecting the "legacy" numbered ones.
|
|
When writing a type-driven search query in rustdoc, specifically one
with more than one query element, non-existent types become generic
parameters instead of auto-correcting (which is currently only done
for single-element queries) or giving no result. You can also force a
generic type parameter by writing `generic:T` (and can force it to not
use a generic type parameter with something like `struct:T` or whatever,
though if this happens it means the thing you're looking for doesn't
exist and will give you no results).
There is no syntax provided for specifying type constraints
for generic type parameters.
When you have a generic type parameter in a search query, it will only
match up with generic type parameters in the actual function, not
concrete types that match, not concrete types that implement a trait.
It also strictly matches based on when they're the same or different,
so `option<T>, option<U> -> option<U>` matches `Option::and`, but not
`Option::or`. Similarly, `option<T>, option<T> -> option<T>`` matches
`Option::or`, but not `Option::and`.
|
|
|
|
|
|
|
|
The default fn ret ty is always unit. Just use that.
Looking back at the time when `FnRetTy` (then called
`FunctionRetTy`) was first added to rustdoc, it seems to originally
be there because `-> !` was a special form: the never type didn't
exist back then.
https://github.com/rust-lang/rust/commit/eb01b17b06eb35542bb80ff7456043b0ed5572ba#diff-384affc1b4190940f114f3fcebbf969e7e18657a71ef9001da6b223a036687d9L921-L924
|
|
|
|
This indexes them as primitives with generics, so `slice<u32>` is
how you search for `[u32]`, and `array<u32>` for `[u32; 1]`.
A future commit will desugar the square bracket syntax to search
both arrays and slices at once.
|
|
|
|
rustdoc: fix type search for `Option` combinators
|
|
rustdoc: sort deprecated items lower in search
closes #98759
### Screenshots
`i32::MAX` show sup above `std::i32::MAX` and `core::i32::MAX`
If just searching for `min`, the deprecated results show up far below other things:
one page later
~~And, as you can see, the "Deprecation planned" message shows up in the search results. The same is true for fully-deprecated items like `mem::uninitialized`:
~~
Edit: the deprecation message change was removed from this PR. Only the sorting is changed.
|
|
serialize `q` (`itemPaths`) sparsely
overall 4% reduction in search index size
|
|
|
|
|
|
|
|
$ wc -c search-index.old.js search-index.new.js
3940530 search-index.old.js
3843222 search-index.new.js
((3940530-3843222)/3940530)*100 = 2.47%
$ wc -c search-index.old.js.gz search-index.new.js.gz
380251 search-index.old.js.gz
379434 search-index.new.js.gz
((380251-379434)/380251)*100 = 0.214%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reduces the size of the function signature index, because
it's common to have many functions that operate on the same types.
$ wc -c search-index-old.js search-index-new.js
5224374 search-index-old.js
3932314 search-index-new.js
By my math, this reduces the uncompressed size of the search index by 32%.
On compressed signatures, the wins are less drastic, a mere 8%:
$ wc -c search-index-old.js.gz search-index-new.js.gz
404532 search-index-old.js.gz
371635 search-index-new.js.gz
|
|
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clippy::map_flatten
clippy::clone_on_copy
clippy::useless_conversion
clippy::needless_arbitrary_self_type
|
|
|
|
|
|
|
|
|
|
Particularly when constructing file paths and fully qualified paths.
This avoids a lot of allocations, speeding things up on almost all
examples.
|
|
This issue was fixed using a hacky recursion "fuel" argument, but the
issue was never minimized nor was a regression test added. The
underlying bug is still unfixed, so this test should help with fixing it
and removing the `recurse` hack.
|
|
|
|
|
|
|
|
Now the only two crate-public items are `build_index` and
`get_index_search_type` (because for some reason the latter is also used
in `formats::cache`).
|
|
It was previously defined in `render::search_index` but wasn't used at
all there. `clean::types` seems like a better fit since that's where
`ExternalCrate` is defined.
|
|
Based on
https://github.com/rust-lang/rust/pull/80883#issuecomment-774437832.
The `tcx` parameters do seem to be used though, so I only removed the
`cache` parameters.
|
|
The old name wasn't very clear, while the new one makes it clear that
this is the code responsible for creating the search index.
|
