Fix ICE when rustdoc encounters certain usages of HRTBs
Fixes#51236
Under certain circumstances, `AutoTraitFinder` could end up computing a `ParamEnv` involving two trait predicates that differed only in the region parameters involved. One of these parameters would be a HRTB, while the other would be a normal region parameter.
When this `ParamEnv` was later passed to `SelectionContext`, an `Ambiguity` error would occur, since the erased versions of these predicates would be identical. To solve the issue, we de-duplicate our list of predicates as we build it up. Whenever we encounter two predicates that differ only in their assignment of region parameters (a HRTB vs a normal lifetime parameter), we pick the HRTB. This corresponds to selecting a 'stricter' bound to display in the generated documentation: we're requiring that a particular type works for all possible lifetime parameters if it's going to implement a particular auto trait.
A type's fully qualified name will now wrap once it gets to the
`[-][src]` link aligned against the right edge of the content area.
Previously the two would overlap and the name would only wrap when
hitting the edge of the content area. The `[-][src]` link will main at
the top of the header.
Make left column of rustdoc search results narrower
To make more room for the description of the item
The description often has useful text that helps disambiguate between search results, but very little of it is shown.
As a side effect, this breaks the alignment between the search results and the "In Return Types" tab, which tends to line up above the description-- up until I started investigating this, I thought "In Names"/"In Parameters"/"In Return Types" were column headers and I just never saw search results that had info for the "In Parameters" middle column! Now, with the two columns of search results each taking up about a half, they look more like tabs than column headers.
Types that are long still wrap and look good-- I made some artificially long types in the following screenshots.
Before screenshot:
<img width="1258" alt="screen shot 2018-08-03 at 8 32 35 pm" src="https://user-images.githubusercontent.com/193874/43670805-56e3b3b4-975e-11e8-9296-600837d03de2.png">
After screenshot:
<img width="1239" alt="screen shot 2018-08-03 at 8 31 17 pm" src="https://user-images.githubusercontent.com/193874/43670810-6591f9ac-975e-11e8-9e12-4ea9ab1e5806.png">
By adding empty `after` content that clears and is `display: block`.
Technique found here: https://stackoverflow.com/a/7817313/51683
Now any part of a documentation search result that is highlighted when
you hover over it should also be clickable.
Parsing the code block's LangString (```foo) previously checked itself
to see if we were on nightly; that isn't the right place to do so. Move
that check slightly outwards to better abstract LangString.
(This is also an optimization as we avoid the costly environment
variable load of RUSTC_BOOTSTRAP).
[NLL] Fix some things for bootstrap
Some changes that are required when bootstrapping rustc with NLL enabled.
* Remove a bunch of unused `mut`s that aren't needed, but the existing lint doesn't catch.
* Rewrite a function call to satisfy NLL borrowck. Note that the borrow is two-phase, but gets activated immediately by an unsizing coercion.
cc #51823
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
