Remove unnecessary `Option` wrapping around `Crate.module`
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
Slight visual improvements to warning boxes in the docs
First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.
Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.
I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.
I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:
Blue = friendly, "use it".
Red = danger, "don't use it".
And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.
However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.
This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
Allow not emitting `uwtable` on Android
`uwtable` is marked as required on Android, so it can't be disabled via `-C force-unwind-tables=no`. However, I found that the reason it's marked as required was to resolve a [backtrace issue in Gecko](https://github.com/rust-lang/rust/issues/49867), and I haven't find any other reasons that make it required ([yet](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Unwind.20tables.20are.20strictly.20required.20on.20Windows.20and.20Android)). Therefore, I assume it's safe to turn it off if a (nice) backtrace is not needed, and submit this PR to allow `-C force-unwind-tables=no` when targeting Android.
Note that I haven't tested this change on Android as I don't have an Android environment for testing.
Only enable assert_dep_graph when query-dep-graph is enabled.
This is a debugging option. The only effect should be on rustc tests.
r? ``@michaelwoerister``
Sidebar trait items order
We were actually sorting `Symbol` and not `String`, creating a completely invalid sort result. I added a test to prevent regressions.
r? ``@jyn514``
Rename `source` to `span` and `span` to `source`
- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`
*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*
r? `@jyn514`
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
Now that we record the crate's name in its `clean::Item`, pushing the
crate name onto the `stack` causes duplicate paths. E.g., the URL
generated for the path `::foo::bar::baz` would be something like
../foo/foo/bar/baz
With this commit, the URL is corrected to
../foo/bar/baz
rustdoc: Replace pair of `Option`s with an enum
They are never both `None` or both `Some`, so it makes more sense to use
an enum so that we "make impossible states impossible".
Remove theme.js file
Fixes#82616.
The first commit moves the `theme.js` file into `main.js`, which requires to also run a small `.replace` on the `main.js` content.
The second commit is just a small cleanup to centralize DOM ids.
Since it removes a file from rustdoc output: cc `@rust-lang/docs-rs`
cc `@jsha`
r? `@jyn514`
Avoid temporary allocations in `render_assoc_item`
`render_assoc_item` came up as very hot in a profile of rustdoc on
`bevy`. This avoids some temporary allocations just to calculate the
length of the header.
This should be a strict improvement, since all string formatting was
done twice before.
cc #82845
Otherwise you get a lot of instances of `item.span.span()`, which is
just plain confusing. `item.span.inner()` conveys the correct meaning of
"get the type that `clean::Span` wraps".
Download a more recent LLVM version if `src/version` is modified
When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:
```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ... lots of args ...
= note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: could not compile `rustdoc-tool`
```
Helps with https://github.com/rust-lang/rust/issues/81930.
Use TrustedRandomAccess for in-place iterators where possible
This can speed up in-place iterators containing simple casts and transmutes from `Copy` types to any type of same size. `!Copy` types can't be optimized since `TrustedRandomAccess` isn't implemented for those iterators.
```
name on.b ns/iter o1.b ns/iter diff ns/iter diff % speedup
vec::bench_transmute 20 (40000 MB/s) 12 (66666 MB/s) -8 -40.00% x 1.67
```
