[NLL] Use smaller spans for errors involving closure captures
Closes#51170Closes#46599
Error messages involving closures now point to the captured variable/closure args.
r? @pnkfelix
avoid computing liveness for locals that escape into statics
Fixes#52713
I poked at this on the plane and I think it's working -- but I want to do a bit more investigation and double check. The idea is to identify those local variables where the entire value will "escape" into the return -- for them, we don't need to compute liveness, since we know that the outlives relations from the return type will force those regions to be equal to free regions. This should help with html5ever in particular.
- [x] test performance
- [x] verify correctness
- [x] add comments
r? @pnkfelix
cc @lqd
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">
Provide `{to,from}_{ne,le,be}_bytes` functions on integers
If one doesn't view integers as containers of bytes, converting them to
bytes necessarily needs the specfication of encoding.
I think Rust is a language that wants to be explicit. The `to_bytes`
function is basically the opposite of that – it converts an integer into
the native byte representation, but there's no mention (in the function
name) of it being very much platform dependent. Therefore, I think it
would be better to replace that method by three methods, the explicit
`to_ne_bytes` ("native endian") which does the same thing and
`to_{le,be}_bytes` which return the little- resp. big-endian encoding.
Specify reentrancy gurantees of `Once::call_once`
I don't think the docs are clear about what happens in the following code
```rust
static INIT: Once = ONCE_INIT;
INIT.call_once(|| INIT.call_once(|| println!("huh?")));
```
[Playground](https://play.rust-lang.org/?gist=15dde1f68a6ede263c7250c36977eade&version=stable&mode=debug&edition=2015)
Let's "specify" the behavior to make it clear that the current behavior (deadlock I think?) is not a strict guarantee.
volatile operations docs: clarify that this does not help wrt. concurrency
Triggered by https://github.com/rust-lang/rust/pull/52391. Cc @stjepang @Amanieu
Should the intrinsics themselves also get more documentation? They generally do not seem to have much of that.
rustbuild: fix local_rebuild
If we detect a local rebuild (e.g. bootstrap compiler is the same version as target compiler), we set stage to 1.
When trying to build e.g. UnstableBook, we use Mode::ToolBootstrap and stage is 1.
Just allow Mode::ToolBootstrap and stagge != 0 if we are in a local_rebuild
This fixes building current master using current beta (as master hasn't yet been bumped to 1.30).
This should be backported to beta too, as currently we cannot build beta using itself because of that.
r? @alexcrichton
App-lint-cability
@eminence recently pointed out (rust-lang/cargo#5846) that it's
surprising that `cargo fix` (now shipping with Cargo itself!) doesn't
fix very common lint warnings, which is as good of a reminder as any
that we should finish #50723.
(Previously, we did this on the librustc and libsyntax crates in #50724. I filed cmr/this-week-in-rust#685 in hopes of recruiting new contributors to do the rest.)
r? @estebank
