| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
In the collect_intra_doc_links pass, links to a given item that occurred
repeatedly were getting inserted into a Vec<clean::ItemLink> repeatedly.
This led to n^2 behavior (where n = the number of pages generated), particularly
for the intra-doc link on the `Into<U> for T where U: From<T>` blanket
implementation, since that link appears on every single struct page.
|
|
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
|
|
r=GuillaumeGomez
rustdoc: hide `reference` methods in search index
They're hidden in the HTML, so it makes no sense in the search engine for `reference::next` or `reference::shrink` to be shown.
https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/What.20is.20.60reference.3A.3Ashrink.60.3F
|
|
|
|
|
|
in metadata
|
|
|
|
rustdoc: Use more let chain
Got the idea after yesterday's review.
r? `@notriddle`
|
|
|
|
|
|
$ 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%
|
|
Not all uses are converted, a few cases iterating through maps/sets and requiring nontrivial changes are kept.
|
|
|
|
|
|
|
|
This was added in 0b9b4b70683db6ef707755f520f139eb7b92a944 to fix the
spacing on trait pages, but stopped being needed because
791f04e5a47ee78951552c7ed1545b2b01a44c74 stopped styling method-toggle.
By only putting the method-toggle class on actual methods, the JS setting
does the right thing.
|
|
|
|
rustdoc for external def-ids
|
|
And a couple of other naming tweaks
Related to https://github.com/rust-lang/rust/issues/48054
|
|
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used
`-Ztime-passes` for years but only recently learned about `-Ztime`.
What's the difference? Let's look at the `-Zhelp` output:
```
-Z time=val -- measure time of rustc processes (default: no)
-Z time-passes=val -- measure time of each rustc pass (default: no)
```
The `-Ztime-passes` description is clear, but the `-Ztime` one is less so.
Sounds like it measures the time for the entire process?
No. The real difference is that `-Ztime-passes` prints out info about passes,
and `-Ztime` does the same, but only for a subset of those passes. More
specifically, there is a distinction in the profiling code between a "verbose
generic activity" and an "extra verbose generic activity". `-Ztime-passes`
prints both kinds, while `-Ztime` only prints the first one. (It took me
a close reading of the source code to determine this difference.)
In practice this distinction has low value. Perhaps in the past the "extra
verbose" output was more voluminous, but now that we only print stats for a
pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also,
a lot of the "extra verbose" cases are for individual lint passes, and you need
to also use `-Zno-interleave-lints` to see those anyway.
Therefore, this commit removes `-Ztime` and the associated machinery. One thing
to note is that the existing "extra verbose" activities all have an extra
string argument, so the commit adds the ability to accept an extra argument to
the "verbose" activities.
|
|
Instead, it gathers the extra info later, when it's actually requested.
|
|
|
|
This reduces the memory consumption of ItemKind.
|
|
This reduces ItemKind size from 224 bytes to 160 bytes.
|
|
|
|
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
|
|
Hack: many traits and types in std are re-exported from core or alloc. In
general, rustdoc is capable of recognizing these implementations as being
on local types. However, in at least one case, rustdoc gets confused and
labels an implementation as being on a foreign type. To make sure that
confusion doesn't pass on to the reader, consider all implementations in
std, core, and alloc to be on local types.
|
|
rustdoc: Improve calculation of "Impls on Foreign Types"
The existing code to calculate whether an implementation was on a "Foreign Type" was duplicated across the sidebar generation and the page generation. It also came to the wrong conclusion for some cases where both the trait and the "for" type were re-exports.
This PR extracts the logic into a method of `Impl`, breaks it into a multi-line method so it can be commented, and adds a case for when the trait and the "for" type came from the same crate. This fixes some cases - like the platform-specific integer types (`__m256`, `__m128`, etc). But it doesn't fix all cases. See the screenshots below.
[Before](https://doc.rust-lang.org/nightly/std/clone/trait.Clone.html#foreign-impls):
<img src="https://user-images.githubusercontent.com/220205/171338226-59ce6daf-3d76-4bad-bc8d-72a8259a8f43.png" width=200>
[After](https://rustdoc.crud.net/jsha/implementation-is-on-local-type/std/clone/trait.Clone.html):
<img src="https://user-images.githubusercontent.com/220205/171338147-28308a65-1597-4223-be47-9550062404dd.png" width=200>
The remaining types (`CString`, `NulError`, etc) are all from the `alloc` crate, while the `Clone` trait is from the `core` crate. Since `CString` and `Clone` are both re-exported by `std`, they are logically local to each other, but I couldn't figure out a good way to detect that in this code. I figure this is still a good step forward.
Related: #97610
r? `@camelid`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: show implementations on `#[fundamental]` wrappers
Fixes #92940
|
|
This removes a special case that doesn't seem to do anything
any more.
|
|
|
|
|
|
Fixes #92940
|
|
Stop using CRATE_DEF_INDEX outside of metadata encoding.
`CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want. We should not manipulate raw `DefIndex` outside of metadata encoding.
|
|
|
|
`CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want.
|
|
|
|
|
|
This allows to compute the `BodyOwnerKind` from `DefKind` only, and
removes a direct dependency of some MIR queries onto HIR.
As a side effect, it also simplifies metadata, since we don't need 4
flavours of `EntryKind::*Static` any more.
|
|
Signed-off-by: codehorseman <cricis@yeah.net>
|
|
|
