Yuki Okushi [Wed, 15 Jan 2020 12:51:59 +0000 (21:51 +0900)]
Rollup merge of #68233 - danielframpton:update-compiler-builtins, r=alexcrichton
Update compiler_builtins with changes to fix 128 bit integer remainder for aarch64 windows.
I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see #65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Yuki Okushi [Wed, 15 Jan 2020 12:51:58 +0000 (21:51 +0900)]
Rollup merge of #68231 - danielframpton:windows-crosscompile, r=alexcrichton
Better support for cross compilation on Windows.
I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see #65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Without the libpath changes we were trying to link a mix of amd64 and arm64 binaries.
Without the cmake system name change, the llvm build was trying to run an arm64 build tool on the x86_64 build machine.
That said, I haven't tested all different combinations here and am very open to resolving this a different way.
Yuki Okushi [Wed, 15 Jan 2020 12:51:57 +0000 (21:51 +0900)]
Rollup merge of #68230 - danielframpton:update-libssh2-sys, r=alexcrichton
Update libssh2-sys to a version that can build for aarch64-pc-windows…
I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see #65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Yuki Okushi [Wed, 15 Jan 2020 12:51:55 +0000 (21:51 +0900)]
Rollup merge of #68229 - danielframpton:update-iovec, r=alexcrichton
Update iovec to a version with no winapi dependency
I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see #65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Yuki Okushi [Wed, 15 Jan 2020 12:51:54 +0000 (21:51 +0900)]
Rollup merge of #68227 - danielframpton:update-cmake, r=alexcrichton
Update to a version of cmake with windows arm64 support
I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see #65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
Yuki Okushi [Wed, 15 Jan 2020 12:51:43 +0000 (21:51 +0900)]
Rollup merge of #67914 - Aaron1011:fix/const-prop-impossible, r=matthewjasper,oli-obk
Don't run const propagation on items with inconsistent bounds
Fixes #67696
Using `#![feature(trivial_bounds)]`, it's possible to write functions
with unsatisfiable 'where' clauses, making them uncallable. However, the
user can act as if these 'where' clauses are true inside the body of the
function, leading to code that would normally be impossible to write.
Since const propgation can run even without any user-written calls to a
function, we need to explcitly check for these uncallable functions.
Yuki Okushi [Wed, 15 Jan 2020 12:51:42 +0000 (21:51 +0900)]
Rollup merge of #67784 - Mark-Simulacrum:residual-pad-integral, r=dtolnay
Reset Formatter flags on exit from pad_integral
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
A manual check leads me to believe this is the only case where we failed to reset the flags appropriately, but I could have missed something.
bors [Wed, 15 Jan 2020 05:01:10 +0000 (05:01 +0000)]
Auto merge of #66329 - ktrianta:mir-opt-unreachable-propagation, r=oli-obk
Add unreachable propagation mir optimization pass
@oli-obk suggested we create a MIR pass that optimizes away basic blocks that lead only to basic blocks with terminator kind **unreachable**. This is a first take on this, which we started with @gilescope at RustFest Impl Days.
The test currently fails when the compiled program runs (undefined behaviour). Is there a way to avoid running the compiled program?
bors [Wed, 15 Jan 2020 00:56:53 +0000 (00:56 +0000)]
Auto merge of #68118 - skinny121:eager_lit_eval, r=varkor
perf: Eagerly convert literals to consts
Previousely even literal constants were being converted to an `Unevaluted` constant for evaluation later. This seems unecessary as no more information is needed to be able to convert the literal to a mir constant.
Hopefully this will also minimise the performance impact of #67717, as far less constant evaluations are needed.
bors [Tue, 14 Jan 2020 15:29:43 +0000 (15:29 +0000)]
Auto merge of #67711 - Amanieu:fix_unwind_leak, r=alexcrichton
Fix memory leak if C++ catches a Rust panic and discards it
If C++ catches a Rust panic using `catch (...)` and then chooses not to rethrow it, the `Box<dyn Any>` in the exception may be leaked. This PR fixes this by adding the necessary destructors to the exception object.
Yuki Okushi [Tue, 14 Jan 2020 05:02:24 +0000 (14:02 +0900)]
Rollup merge of #68150 - tillarnold:master, r=cramertj
Document behavior of set_nonblocking on UnixListener
The description on `set_nonblocking` in `UnixListener` was rather brief so I adapted it to be more like the documentation of `set_nonblocking` in `TcpListener`.
Yuki Okushi [Tue, 14 Jan 2020 05:02:21 +0000 (14:02 +0900)]
Rollup merge of #68127 - varkor:clarify-extended-option, r=alexcrichton
Clarify the relationship between `extended` and `tools` in `config.toml`
I.e. `tools` is only effective if `extended = true`. Alternatively, we could make `tools = []` by default and remove `extended` (although we'd want to list the possible options), but improving the description seems sufficient to solve the issue.
Yuki Okushi [Tue, 14 Jan 2020 05:02:20 +0000 (14:02 +0900)]
Rollup merge of #68036 - euclio:libterm-ncurses6-fix, r=KodrAus
libterm: parse extended terminfo format
Fixes #45728.
Modifies libterm to parse the extended terminfo format introduced in ncurses 6.1. This fixes the lack of color in test output for users with newer ncurses versions.
The ideal fix for this would be to migrate libtest to use `termcolor` (https://github.com/rust-lang/rust/issues/60349), but that's blocked for the foreseeable future.
Ben Lewis [Sat, 11 Jan 2020 02:22:36 +0000 (15:22 +1300)]
perf: eagerly convert literals to consts, this avoids creating loads on unevaluated consts
which requires a lot of unnecessary work to evaluate them further down the line.
bors [Mon, 13 Jan 2020 17:39:01 +0000 (17:39 +0000)]
Auto merge of #68088 - oli-obk:fix_miri, r=RalfJung
Don't try to force_ptr pointers to zsts
r? @RalfJung
cc @wesleywiser
This is required to fix miri after https://github.com/rust-lang/rust/pull/67501 broke it. The reason only miri sees this is that it uses validation on values during interpretation and not just on the final value of constants, which never contain such values.
bors [Mon, 13 Jan 2020 12:49:12 +0000 (12:49 +0000)]
Auto merge of #67850 - GuillaumeGomez:err-codes-checkup, r=Mark-Simulacrum
Error codes checkup and rustdoc test fix
This PR does a few things:
* fix how rustdoc checks that an error code has been thrown (it only checked for "E0XXX" so if it appeared in the output because the file has it in its name or wherever, it passed the test, which was incorrect)
* fix the failing code examples that weren't throwing the expected error code
Aaron Hill [Mon, 6 Jan 2020 03:32:53 +0000 (22:32 -0500)]
Don't run const propagation on items with inconsistent bounds
Using `#![feature(trivial_bounds)]`, it's possible to write functions
with unsatisfiable 'where' clauses, making them uncallable. However, the
user can act as if these 'where' clauses are true inside the body of the
function, leading to code that would normally be impossible to write.
Since const propgation can run even without any user-written calls to a
function, we need to explcitly check for these uncallable functions.
bors [Mon, 13 Jan 2020 08:20:49 +0000 (08:20 +0000)]
Auto merge of #68174 - JohnTitor:rollup-ix4amrj, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #67313 (Document more use cases of dataflow)
- #67959 (rustdoc: improve stability mark arrows)
- #68097 (Specify units for test timeout environment variables)
- #68135 (restore some rustc_parse visibilities for rustfmt)
- #68145 (Expose `context::CheckLintNameResult`)
- #68156 (Fix crate paths in comments)
- #68157 (Clean up E0186 explanation)
- #68161 (Fix system call docs for time::Instant)
Yuki Okushi [Mon, 13 Jan 2020 07:44:24 +0000 (16:44 +0900)]
Rollup merge of #68161 - ruuda:fix-instant-docs, r=rkruppe
Fix system call docs for time::Instant
The link for UNIX was pointing to the Cloud ABI docs. It should have been pointing to the `clock_gettime` docs instead. A similar table is repeated in the docs for `SystemTime`, but there the UNIX entry was already correct.
Yuki Okushi [Mon, 13 Jan 2020 07:44:18 +0000 (16:44 +0900)]
Rollup merge of #68135 - calebcartwright:rustc-parse-visibilities, r=Centril
restore some rustc_parse visibilities for rustfmt
In https://github.com/rust-lang/rust/pull/65495/commits/c189565edc5c9fc516170885b3a3061b936205fb some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible.
This restores the visibility on those items rustfmt depends on.
The link for UNIX was pointing to the Cloud ABI docs. It should have
been pointing to the clock_gettime docs instead. The table is repeated
in the docs for SystemTime, but there the UNIX entry was already correct.
bors [Sun, 12 Jan 2020 02:28:48 +0000 (02:28 +0000)]
Auto merge of #68142 - Centril:rollup-dl232e9, r=Centril
Rollup of 6 pull requests
Successful merges:
- #67494 (Constify more of alloc::Layout)
- #67867 (Correctly check for opaque types in `assoc_ty_def`)
- #67948 (Galloping search for binary_search_util)
- #68045 (Move more of `rustc::lint` into `rustc_lint`)
- #68089 (Unstabilize `Vec::remove_item`)
- #68108 (Add suggestions when encountering chained comparisons)
Rollup merge of #68108 - varkor:chained-comparison-suggestions, r=Centril
Add suggestions when encountering chained comparisons
Ideally, we'd also prevent the type error, which is just extra noise, but that will require moving the error from the parser, and I think the suggestion makes things clear enough for now.
Rollup merge of #68045 - Centril:liberate-lints, r=Mark-Simulacrum
Move more of `rustc::lint` into `rustc_lint`
Based on https://github.com/rust-lang/rust/pull/67806.
Here we try to consolidate more of the linting infra into `rustc::lint`. Some high-level notes:
- We now store an `Lrc<dyn Any + Send + Sync>` as opposed to `Lrc<LintStore>` in the `GlobalCtxt`. This enables us to avoid referring to the type, breaking a cyclic dependency, and so we can move things from `rustc::lint` to `rustc_lint`.
- `in_derive_expansion` is, and needs to, be moved as a method on `Span`.
- We reduce the number of ways on `tcx` to emit a lint so that the developer UX is more streamlined.
- `LintLevelsBuilder` is moved to `rustc_lint::levels`, leaving behind `LintLevelMap/Set` in a purified form due to current constraints (hopefully fixable in the future after https://github.com/rust-lang/rust/pull/68133).
- `struct_lint_level` is moved to `rustc::lint` due to current dependency constraints.
- `rustc::lint::context` is moved to `rustc_lint::context`.
- The visitors in `rustc::lint` are moved to `rustc_lint::passes`.
Rollup merge of #67494 - lukaslueg:const_alloc, r=oli-obk
Constify more of alloc::Layout
Making more methods of `alloc::Layout` const would allow us to compute alignment/size information for arbitrary (sized) types at compile-time, including placing the information in associated constants. While `mem::size_of` and `mem::align_of` are already const and `Layout` is solely based on those, there is no guarantee in the implementation that a const derived from these functions will be exactly the same as what `Layout` uses and is subsequently used in a call to `alloc::alloc`. Constifying `Layout` makes this possible.