Optimize miri checking of integer array/slices
This pull request implements the optimization described in #53845 (the `E-easy` part of that issue, not the refactoring). Instead of checking every element of an integral array, we can check the whole memory range at once.
r? @RalfJung
Rollup of 10 pull requests
Successful merges:
- #53315 (use `NonZeroU32` in `newtype_index!`macro, change syntax)
- #53932 ([NLL] Remove base_place)
- #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.)
- #53973 (Have rust-lldb look for the rust-enabled lldb)
- #53981 (Implement initializer() for FileDesc)
- #53987 (rustbuild: allow configuring llvm version suffix)
- #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
- #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint)
- #54040 (update books for next release)
- #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)
use `NonZeroU32` in `newtype_index!`macro, change syntax
Various improvements to the `newtype_index!` macro:
- Use `NonZeroU32` so that `Option<T>` is cheap
- More ergonomic helper method, no need to import `Idx` trait all the time
- Improve syntax to use `struct` keyword so that ripgrep works to find type def'n
Fixes https://github.com/rust-lang/rust/issues/50337
I'm curious to see if this passes tests =)
Update `petgraph` dependency to 0.4.13 to fix build with nightly
I wanted to build Rust from source using a local nightly compiler, but I was unable to get `bootstrap` to compile due to a naming conflict with the `find_map` function.
This PR updates the `petgraph` dependency of `bootstrap` to 0.4.13, fixing the issue.
Implement initializer() for FileDesc
Here was my initial issue:
```rust
use std::process::{Command};
fn main() {
let output = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").output();
println!("{:?}", output.unwrap().stdout.len());
}
```
```
~/stuff ❯❯❯ time ./dwl
104857600
./dwl 16.22s user 1.80s system 23% cpu 1:15.24 total
```
```rust
use std::process::{Command, Stdio};
fn main() {
let child = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").stdout(Stdio::piped()).spawn();
let output = child.unwrap().wait_with_output().unwrap();
println!("{:?}", output.stdout.len());
}
```
```
~/stuff ❯❯❯ time ./dwl2
104857600
./dwl2 0.64s user 2.18s system 5% cpu 53.072 total
```
As you can see the first version is spending much more time in userland and also uses more cpu. With the help of @programble, @talchas and @habnabit on the rust IRC, we discovered that the slow version uses two pipes, one for `stdin` and one for `stderr` and in that case it polls when going through [this function](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/pipe.rs#L82). The polling calls `read_to_end` on the pipes repetitively and this results in zeroing its internal buffer each time. To avoid this zeroing, `FileDesc` needs to implement `initializer`. We see no reason why it [wouldn't work with uninitialized memory](https://doc.rust-lang.org/1.26.1/src/std/io/mod.rs.html#534) so this PR fixes that.
Here is some tracing of the slow program:
versus the fast program:
I have not tested the change yet but will try to build it tomorrow.
Have rust-lldb look for the rust-enabled lldb
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed. This patch changes
rust-lldb to look in the sysroot and use the lldb found there, if any.
See issue #48168
Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.
It now does one hash table lookup per basic block, instead of one per
statement. This is worthwhile because this function is hot for NLL
builds of `ucd`.
I haven't measured the effect of this yet because I'm having trouble doing optimized builds of rustc that are suitable for profiling (#53916). I will do an online perf run instead.
r? @nikomatsakis
[NLL] Remove base_place
This function was supposed to make `Box` less special. But
* I think that the consensus is that MIR borrowck is going to fully special case `Box`
* It wasn't implemented correctly, it's looking at the type of the wrong `Place`, resulting in weird behaviour:
```rust
#![feature(nll)]
type A = Box<i32>; // If this is changed to another type then this will compile.
pub fn foo(x: Box<(String, A)>) {
let a = x.0; // This will compile if these lines are swapped
let b = x.1;
}
```
r? @nikomatsakis
stabilize #[panic_handler]
closes#44489
### Update(2018-09-07)
This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946
Documentation PRs:
- Reference. https://github.com/rust-lang-nursery/reference/pull/362
- Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75
---
`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.
(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054
Some unresolved questions from #44489:
> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".
The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.
> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?
I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?
---
Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.
cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
do not propagate closure requirements if we can prove them locally
Fixes#53570
cc @mikhail-m1 -- you're the one who last touched this code
r? @pnkfelix
This allows it to print out the "late-bound regions" from the closure
context more easily. Besides, all the state that is being printed it
is private to the `UniversalRegions`.
[nll] teach SCC about `'static`
r? @nikomatsakis
I think this is right? I am seeing better performance on the `html5ever` benchmark but I'd like a perf run to quantify the exact speedup. There's a few ui tests failing due to changes in the error messages. The main issue seems to be that returns aren't being detected correctly?
`mir_check_cast_unsize.rs` before:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:17:46
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| ________--____________________________________^
| | |
| | lifetime `'a` defined here
18 | | //~^ ERROR unsatisfied lifetime constraints
19 | | x
20 | | //~^ WARNING not reporting region error due to nll
21 | | }
| |_^ return requires that `'a` must outlive `'static`
```
`mir_check_cast_unsize.rs` after:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:19:5
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| -- lifetime `'a` defined here
18 | //~^ ERROR unsatisfied lifetime constraints
19 | x
| ^ cast requires that `'a` must outlive `'static`
```
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.
This patch changes dist.rs to put lldb into rustlib, following what
was done for the other LLVM tools in #53955, and then fixes rust-lldb
to prefer that lldb, if it exists.
See issue #48168
Rollup of 17 pull requests
Successful merges:
- #53299 (Updated core/macros.rs to note it works in a no_std environment.)
- #53376 (Cross reference io::copy and fs::copy in docs.)
- #53455 (Individual docs for {from,to}_*_bytes)
- #53550 (librustc_lint: In recursion warning, change 'recurring' to 'recursing')
- #53860 (Migrate (some) of run-pass/ to ui)
- #53874 (Implement Unpin for Box, Rc, and Arc)
- #53895 (tidy: Cleanups and clippy warning fixes)
- #53946 (Clarify `ManuallyDrop` docs)
- #53948 (Minimized clippy test from when NLL disabled two-phase borrows)
- #53959 (Add .git extension to submodule paths missing it)
- #53966 (A few cleanups and minor improvements to mir/dataflow)
- #53967 (propagate build.python into cmake)
- #53979 (Remove `#[repr(transparent)]` from atomics)
- #53991 (Add unchecked_shl/shr check for intrinsics to fix miri's test suit)
- #53992 (migrate run-pass/borrowck to ui/run-pass)
- #53994 (migrate run-pass/*/ to ui/run-pass)
- #54023 (update clippy submodule)
Remove `#[repr(transparent)]` from atomics
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
propagate build.python into cmake
If a suitable value of Python is not on `PATH`, one can still invoke x.py
manually, which propagates `BOOTSTRAP_PYTHON` into the bootstrap
environment. But building LLVM will abort with error messages about not
being able to find Python, and instructions to set `PYTHON_EXECUTABLE`,
because nothing is done with `BOOTSTRAP_PYTHON` when invoking cmake.
Setting `build.python` in config.toml had no effect in this scenario,
either
To fix this, let's provide `PYTHON_EXECUTABLE` when invoking cmake; for
the "normal" case of Python in `PATH`, this doesn't alter any behavior.
For more unusual cases, however, this ensures cmake finds Python
properly. (This change also ensures there are no differences between
what bootstrap is using, and what cmake uses, which may be useful for
consistency's sake.)
A few cleanups and minor improvements to mir/dataflow
- simplify `dot::GraphWalk::edges` and optimize its vector's allocation
- turn a `kill` loop into `kill_all`
- remove the `prepost` parameter from `dataflow_path` (it doesn't seem to do anything)
- a couple of other minor improvements
