Rust 1.7.0 and newer appears to require LLVM 3.6.0 or newer when
building against a version that's out of the tree with the --llvm-root
flag.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
This hack has long since outlived its usefulness; the transition to
trans passing around full substitutions is basically done. Instead of
`ErasedRegions`, just supply substitutions with a suitable number of
`'static` entries, and invoke `erase_regions` when needed (the latter of
which we already do).
Make warnings of renamed and removed lints themselves lints
This adds the `renamed_and_removed_lints` warning, defaulting
to the warning level.
Fixes#31141
while I'm at it, remove the "extra caching" that I was doing for no good
reason except laziness. Basically before I was caching at each scope in
the chain, but there's not really a reason to do that, since the cached
entry point at level N is always equal to the last cached exit point
from level N-1.
Index 0 must be a valid char boundary (invariant of str that it contains
valid UTF-8 data).
If we check explicitly for index == 0, that removes the need to read the
byte at index 0, so it avoids a trip to the string's memory, and it
optimizes out the slicing index' bounds check whenever it is zero.
With this change, the following examples all change from having a read of
the byte at 0 and a branch to possibly panicing, to having the bounds
checking optimized away.
```rust
pub fn split(s: &str) -> (&str, &str) {
s.split_at(0)
}
pub fn both(s: &str) -> &str {
&s[0..s.len()]
}
pub fn first(s: &str) -> &str {
&s[..0]
}
pub fn last(s: &str) -> &str {
&s[0..]
}
```
It's nice to be able to index with a scope-id,
but coherence rules prevent us from implementing
`Index<ScopeId>` for `Vec<ScopeAuxiliary>`, and I'd
prefer that `ScopeAuxiliary` remain in librustc_mir,
just for compilation time reasons.
This was triggered by me wanting to address a use of DUMMY_SP, but
actually I'm not sure what would be a better span -- I guess the span
for the function as a whole.
Docs: Change "statements" to "expressions" on `match`
I apt to use `expressions` over `statements`, because `match` is a expression in essence, though it can become a statement when followed a semicolon.
