bors [Thu, 14 May 2020 06:22:40 +0000 (06:22 +0000)]
Auto merge of #69756 - wesleywiser:simplify_try, r=oli-obk
Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1
I also added test cases to make sure the optimization can fire on all of
these cases:
```rust
fn case_1(o: Option<u8>) -> Option<u8> {
match o {
Some(u) => Some(u),
None => None,
}
}
fn case2(r: Result<u8, i32>) -> Result<u8, i32> {
match r {
Ok(u) => Ok(u),
Err(i) => Err(i),
}
}
fn case3(r: Result<u8, i32>) -> Result<u8, i32> {
let u = r?;
Ok(u)
}
```
Without MIR inlining, this still does not completely optimize away the
`?` operator because the `Try::into_result()`, `From::from()` and
`Try::from_error()` calls still exist. This does move us a bit closer to
that goal though because:
- We can now run the pass on mir-opt-level=1
- We no longer depend on the copy propagation pass running which is
unlikely to stabilize anytime soon.
bors [Thu, 14 May 2020 02:50:34 +0000 (02:50 +0000)]
Auto merge of #72058 - RalfJung:no-dist-lldb, r=Mark-Simulacrum
bootstrap: remove lldb dist packaging
The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in #62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit.
The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.
We should establish a process on how often and when to update Clippy. (After X feature PRs? Once per week? Only on bug fixes and in the release week? ...?)
bors [Wed, 13 May 2020 14:29:56 +0000 (14:29 +0000)]
Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic, r=Amanieu
Make `RawVec::grow` mostly non-generic.
`cargo-llvm-lines` shows that, in various benchmarks, `RawVec::grow` is
instantiated 10s or 100s of times and accounts for 1-8% of lines of
generated LLVM IR.
This commit moves most of `RawVec::grow` into a separate function that
isn't parameterized by `T`, which means it doesn't need to be
instantiated many times. This reduces compile time significantly.
bors [Tue, 12 May 2020 10:28:08 +0000 (10:28 +0000)]
Auto merge of #72134 - Dylan-DPC:rollup-h3shfz5, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #71737 (Miri: run liballoc tests with threads)
- #71928 (Add strikethrough support to rustdoc)
- #72048 (Visit move out of `_0` when visiting `return`)
- #72096 (Make MIR typeck use `LocalDefId` and fix docs)
- #72128 (strings do not have to be valid UTF-8 any more)
The amortized case is much more common than the exact case, and it is
typically instantiated many times.
Also, we can put a chunk of the code into a function that isn't generic
over T, which reduces the amount of LLVM IR generated quite a lot,
improving compile times.
It's only used once, for `VecDeque`, and can easily be replaced by
something else. The commit changes `grow_if_necessary` to `grow` to
avoid some small regressions caused by changed inlining.
The commit also removes `Strategy::Double`, and streamlines the
remaining variants of `Strategy`.
It's a compile time win on some benchmarks because the many
instantations of `RawVec::grow` are a little smaller.
Wesley Wiser [Tue, 12 May 2020 00:13:15 +0000 (20:13 -0400)]
Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1
I also added test cases to make sure the optimization can fire on all of
these cases:
```rust
fn case_1(o: Option<u8>) -> Option<u8> {
match o {
Some(u) => Some(u),
None => None,
}
}
fn case2(r: Result<u8, i32>) -> Result<u8, i32> {
match r {
Ok(u) => Ok(u),
Err(i) => Err(i),
}
}
fn case3(r: Result<u8, i32>) -> Result<u8, i32> {
let u = r?;
Ok(u)
}
```
Without MIR inlining, this still does not completely optimize away the
`?` operator because the `Try::into_result()`, `From::from()` and
`Try::from_error()` calls still exist. This does move us a bit closer to
that goal though because:
- We can now run the pass on mir-opt-level=1
- We no longer depend on the copy propagation pass running which is
unlikely to stabilize anytime soon.
Dylan DPC [Mon, 11 May 2020 20:20:55 +0000 (22:20 +0200)]
Rollup merge of #72027 - Mark-Simulacrum:ci-caches, r=pietroalbini
Use CDN for ci-caches on download
This will reduce costs, as well as lays the groundwork for developers to be able
to locally pull the published docker images without needing AWS credentials.
I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker, PtxLinker, MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.
bors [Sun, 10 May 2020 12:07:34 +0000 (12:07 +0000)]
Auto merge of #72074 - RalfJung:rollup-1ns58no, r=RalfJung
Rollup of 4 pull requests
Successful merges:
- #71840 (Rework MIR drop tree lowering)
- #71882 (Update the `cc` crate)
- #71945 (Sort "implementations on foreign types" section in the sidebar)
- #72043 (Add missing backtick in E0569 explanation)
Ralf Jung [Sun, 10 May 2020 09:34:34 +0000 (11:34 +0200)]
Rollup merge of #71945 - GuillaumeGomez:sort-impl-on-foreign-types-section, r=kinnison,ollie27
Sort "implementations on foreign types" section in the sidebar
Fixes #71926.
We were sorting by the ID instead of sorting by the name. They're not in the same order as the implementations but I think it makes more sense this way considering this is what we do for the methods as well.
Ralf Jung [Sun, 10 May 2020 09:34:30 +0000 (11:34 +0200)]
Rollup merge of #71840 - matthewjasper:drop-trees, r=oli-obk
Rework MIR drop tree lowering
This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949.
Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed, the required drops are recorded and get generated later.
The motivation for this is
* It simplifies the caching scheme, because it's now possible to walk up the currently scheduled drop tree to recover state.
* The basic block order for MIR more closely resembles execution order.
This PR also:
* Highlights cleanup blocks in the graphviz MIR output.
* Removes some unnecessary drop flag assignments.
bors [Sun, 10 May 2020 04:41:01 +0000 (04:41 +0000)]
Auto merge of #72020 - alexcrichton:fix-incremental-linker-plugin-lto, r=oli-obk
Fix disagreeement about CGU reuse and LTO
This commit fixes an issue where the codegen backend's selection of LTO
disagreed with what the codegen later thought was being done. Discovered
in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in
optimized mode is compiled incrementally it will always panic on the
second compilation. The underlying issue turned out to be that the
production of the original artifact determined that LTO should not be
done (because it's being postponed to the linker) but the CGU reuse
selection thought that LTO was done so it was trying to load pre-LTO
artifacts which were never generated.
The fix here is to ensure that the logic when generating code which
determines what kind of LTO is being done is shared amongst the CGU
reuse decision and the backend actually doing LTO. This means that
they'll both be in agreement about whether the previous compilation did
indeed produce incremental pre-LTO artifacts.
Alex Crichton [Fri, 8 May 2020 16:27:59 +0000 (09:27 -0700)]
Fix disagreeement about CGU reuse and LTO
This commit fixes an issue where the codegen backend's selection of LTO
disagreed with what the codegen later thought was being done. Discovered
in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in
optimized mode is compiled incrementally it will always panic on the
second compilation. The underlying issue turned out to be that the
production of the original artifact determined that LTO should not be
done (because it's being postponed to the linker) but the CGU reuse
selection thought that LTO was done so it was trying to load pre-LTO
artifacts which were never generated.
The fix here is to ensure that the logic when generating code which
determines what kind of LTO is being done is shared amongst the CGU
reuse decision and the backend actually doing LTO. This means that
they'll both be in agreement about whether the previous compilation did
indeed produce incremental pre-LTO artifacts.
bors [Sat, 9 May 2020 18:43:28 +0000 (18:43 +0000)]
Auto merge of #5564 - MrAwesome:master, r=flip1995
Allow `use super::*;` glob imports
changelog: Allow super::* glob imports
fixes #5554
fixes #5569
A first pass at #5554 - this allows all `use super::*` to pass, which may or may not be desirable. The original issue was around allowing test modules to import their entire parent modules - I'm happy to modify this to do that instead, may just need some guidance on how to implement that (I played around a bit with #[cfg(test)] but from what I can gather, clippy itself isn't in test mode when running, even if the code in question is being checked for the test target).
bors [Sat, 9 May 2020 17:31:08 +0000 (17:31 +0000)]
Auto merge of #72041 - RalfJung:rollup-xivrvy2, r=RalfJung
Rollup of 5 pull requests
Successful merges:
- #69406 (upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir)
- #71185 (Move tests from `test/run-fail` to UI)
- #71234 (rustllvm: Use .init_array rather than .ctors)
- #71508 (Simplify the `tcx.alloc_map` API)
- #71555 (Remove ast::{Ident, Name} reexports.)
Ralf Jung [Sat, 9 May 2020 11:36:37 +0000 (13:36 +0200)]
Rollup merge of #71508 - oli-obk:alloc_map_unlock, r=RalfJung
Simplify the `tcx.alloc_map` API
This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private.
Ralf Jung [Sat, 9 May 2020 11:36:32 +0000 (13:36 +0200)]
Rollup merge of #71234 - maurer:init-array, r=cuviper
rustllvm: Use .init_array rather than .ctors
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````
I'd like to get the fix for https://github.com/rust-lang/cargo/issues/8223 into nightly asap.
bors [Sat, 9 May 2020 06:26:57 +0000 (06:26 +0000)]
Auto merge of #71994 - jyn514:path-independent, r=Mark-Simulacrum
x.py: allow configuring the build directory
This allows configuring the directory for build artifacts, instead of having it always be `./build`. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in `config.toml` under `build.build-dir`. By default, it keeps the existing default of `./build`, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using `$ROOT`.
Dylan DPC [Sat, 9 May 2020 01:10:09 +0000 (03:10 +0200)]
Rollup merge of #71942 - nnethercote:shrink-LocalDecl, r=matthewjasper
Shrink `LocalDecl`
`LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit, and does some clean-ups as well.
Dylan DPC [Sat, 9 May 2020 01:10:01 +0000 (03:10 +0200)]
Rollup merge of #70834 - yoshuawuyts:future-pending-ready, r=sfackler
Add core::future::{pending,ready}
Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.
These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.
## Examples
In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:
```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;
pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
let mut fut = future::ready(42_u8);
let num = ready!(Pin::new(fut).poll(cx));
// ... use num
Poll::Ready(())
}
```
## Why future::ready?
Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).
The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.