Pass --cfg=bootstrap for rustdoc for proc_macro crates
This PR does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc invocations on proc_macro crates. This mirrors what we do already for rustc invocations of those, and is needed because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected. This is needed both on later stages where it's not set, but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e .
rustdoc: remove no-op CSS on `.source .content`
# `margin-left: 0`
This rule originated in 7669f04fb0, to override the default, massive left margin that content used to accommodate the sidebar:
7669f04fb0/src/librustdoc/html/static/main.css (L307-L309)
This massive left margin doesn't exist any more. It was replaced with a flexbox-based sidebar layout in 135281ed15.
# `max-width: none`
This rule originated in 7669f04fb0, to override the default, limited line-width that makes sense for prose, but doesn't make sense for code (which typically uses hard-wrapped lines):
7669f04fb0/src/librustdoc/html/static/main.css (L153)
This line width limiter isn't applied to the `<div class="content">` node any more. It's been moved to a separate wrapper `<div>` that used to be called `main-inner` (in 135281ed15) but is now called `width-limiter` (since d7528e2157).
Remove some unused CSS rules
Since we now have list of items for the ones on the page, we don't need the CSS rules anymore in the sidebar (`.sidebar a`). As for the `.content` ones, they are used to highlight the items in the page (for definitions and others). Surprisingly enough, `method` and `tymethod` are all replaced with `fnname`.
I also used this opportunity to remove these rules in `ayu.css`:
```css
.stab.unstable {}
h2,
h3:not(.impl):not(.method):not(.type):not(.tymethod), h4:not(.method):not(.type):not(.tymethod) {}
```
In the second commit, I removed the `.block a.current*` CSS rules as they're overridden by `.sidebar a.current*` CSS rules.
In the third commit I removed unneeded empty rules (that were there to satisfy the `--check-theme` option).
cc ``@jsha``
r? ``@notriddle``
This was originally added so those doc pages could use the same font
files, but it turns out to be fragile. And those doc pages are just
stubs that link to other pages, so they don't need fancy fonts.
This CL modifies the handing of env vars during the bootstrap process in
two ways:
1. Replaces '-' characters with '_' characters in target names to
increase compatibility with different shells
2. Passes Stage0 snapshot compiler related env vars to early invocations
of Cargo
This commit does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc
invocations on proc_macro crates. This mirrors what we
do already for rustc invocations of those, and is needed
because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS
when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected.
This is needed both on later stages where it's not set,
but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better
reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e .
This rule originated in 7669f04fb0, to
override the default, limited line-width that makes sense for prose, but
doesn't make sense for code (which typically uses hard-wrapped lines):
7669f04fb0/src/librustdoc/html/static/main.css (L153)
This line width limiter isn't applied to the `<div class="content">` node
any more. It's been moved to a separate wrapper `<div>` that used to be
called `main-inner` (in 135281ed15) but is
now called `width-limiter` (since
d7528e2157).
Use memmem when searching for usages in ide-db
We already have this dependency, so there is no reason not to use it as it is generally faster than std in our use case.
