Simply move the test for `keywords::StaticLifetime` into the
`Lifetime` impl, to match how elision is checked.

I realized that, even in the current system, such reads can't really do
any harm. Because they are not part of a task, they will occur no matter
what (only tasks can be skipped). If you leak the data you read into a
task, that is bad, but that is equally bad if you are in a task.

*Writes* to tracked state, on the other hand, should never occur except
from within a task (and the task then records what things you read to
compute it).

Once we complete the shift to on-demand, these properties will hold by
construction (because the on-demand struct enforces stateless tasks
where leaks are impossible -- except by having shared mutable state in
the tcx).

Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:

* Relying on run-time data means we can't show concrete examples of how
  these methods work up-front. The user is required to run them in order
  to see how they behave.
* If the user tries to run an example in the playpen, it won't work
  because the playpen doesn't support user input to stdin.

This change slightly changes the main iteration loop so that LLVM can
optimize it more efficiently.

Benchmark:

name                                   before ns/iter   after ns/iter    diff ns/iter   diff %
slice::sort_unstable_small_ascending   39 (2051 MB/s)   38 (2105 MB/s)             -1   -2.56%
slice::sort_unstable_small_big_random  579 (2210 MB/s)  575 (2226 MB/s)            -4   -0.69%
slice::sort_unstable_small_descending  80 (1000 MB/s)   70 (1142 MB/s)            -10  -12.50%
slice::sort_unstable_small_random      396 (202 MB/s)   386                       -10   -2.53%

Previously a `'static` lifetime bound would result in an `undeclared
lifetime` error when compiling, even though it could be considered
valid.

However, it is unnecessary to use it as a lifetime bound so we present
the user with a warning instead and suggest using the `'static` lifetime
directly, in place of the lifetime parameter.

…=GuillaumeGomez

Rewrite `io::BufRead` doc examples to better demonstrate behaviors.

Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:

* Relying on run-time data means we can't show concrete examples of how
  these methods work up-front. The user is required to run them in order
  to see how they behave.
* If the user tries to run an example in the playpen, it won't work
  because the playpen doesn't support user input to stdin.

Add warning for use of lifetime parameter with 'static bound

Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.

However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.

Example output:
```
warning: unnecessary lifetime parameter `'a`
 --> ../static-lifetime-bound.rs:3:10
  |
3 | fn f<'a: 'static>(val: &'a i32) {
  |      ^^^^^^^^^^^
  |
  = help: you can use the `'static` lifetime directly, in place `'a`
```

Fixes rust-lang#40661

r? @jseyfried

…-doc, r=steveklabnik

Basic documentation for inclusive range syntax

Done so that we can remove mention of this from the stable documentation ⚠️.

…cess-levels, r=eddyb

"on-demandify" privacy and access levels

r? @eddyb
cc @cramertj rust-lang#40746

…=alexcrichton

Optimize insertion sort

This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.

Benchmark:

```
name                                   before ns/iter   after ns/iter    diff ns/iter   diff %
slice::sort_unstable_small_ascending   39 (2051 MB/s)   38 (2105 MB/s)             -1   -2.56%
slice::sort_unstable_small_big_random  579 (2210 MB/s)  575 (2226 MB/s)            -4   -0.69%
slice::sort_unstable_small_descending  80 (1000 MB/s)   70 (1142 MB/s)            -10  -12.50%
slice::sort_unstable_small_random      396 (202 MB/s)   386                       -10   -2.53%
```

The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.

…rntSushi

Fix typo in dec2flt/algorithm.rs