Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 12 pull requests #68248

Merged
merged 31 commits into from
Jan 15, 2020
Merged

Rollup of 12 pull requests #68248

merged 31 commits into from
Jan 15, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

Mark-Simulacrum and others added 30 commits January 1, 2020 15:22
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.
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.
This avoids a strange linker error that we get with only "--emit=mir"
and "check-pass"
This was causing an ICE when enabling trace logging for an unrelated
module, since the arguments to `trace!` ended up getting evaluated
…al, 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.
…, r=matthewjasper,oli-obk

Don't run const propagation on items with inconsistent bounds

Fixes rust-lang#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.
…, r=alexcrichton

use winapi for non-stdlib Windows bindings
…e0170, r=Dylan-DPC

Add failing example for E0170 explanation

r? @Dylan-DPC
…wiser

Untangle ZST validation from integer validation and generalize it to all zsts

cc @RalfJung

r? @wesleywiser
…nnytm

Update the wasi-libc bundled with libstd
…ewjasper

Avoid calling tcx.hir().get() on CRATE_HIR_ID

This was causing an ICE when enabling trace logging for an unrelated
module, since the arguments to `trace!` ended up getting evaluated
…crichton

Update to a version of cmake with windows arm64 support

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
…crichton

Update iovec to a version with no winapi dependency

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
…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 rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
…, r=alexcrichton

Better support for cross compilation on Windows.

I have been investigating enabling panic=unwind for aarch64-pc-windows-msvc (see rust-lang#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.
…tins, 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 rust-lang#65313) and building rustc and cargo hosted on aarch64-pc-windows-msvc.
@JohnTitor
Copy link
Member Author

@bors r+ p=12 rollup=never

@bors
Copy link
Contributor

bors commented Jan 15, 2020

📌 Commit d2840e6 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 15, 2020
@JohnTitor JohnTitor added the rollup A PR which is a rollup label Jan 15, 2020
bors added a commit that referenced this pull request Jan 15, 2020
Rollup of 12 pull requests

Successful merges:

 - #67784 (Reset Formatter flags on exit from pad_integral)
 - #67914 (Don't run const propagation on items with inconsistent bounds)
 - #68141 (use winapi for non-stdlib Windows bindings)
 - #68211 (Add failing example for E0170 explanation)
 - #68219 (Untangle ZST validation from integer validation and generalize it to all zsts)
 - #68222 (Update the wasi-libc bundled with libstd)
 - #68226 (Avoid calling tcx.hir().get() on CRATE_HIR_ID)
 - #68227 (Update to a version of cmake with windows arm64 support)
 - #68229 (Update iovec to a version with no winapi dependency)
 - #68230 (Update libssh2-sys to a version that can build for aarch64-pc-windows…)
 - #68231 (Better support for cross compilation on Windows.)
 - #68233 (Update compiler_builtins with changes to fix 128 bit integer remainder for aarch64 windows.)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jan 15, 2020

⌛ Testing commit d2840e6 with merge 6d0bb91...

@bors
Copy link
Contributor

bors commented Jan 15, 2020

☀️ Test successful - checks-azure
Approved by: JohnTitor
Pushing 6d0bb91 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 15, 2020
@bors bors merged commit d2840e6 into rust-lang:master Jan 15, 2020
@JohnTitor JohnTitor deleted the rollup-x0kml5f branch January 15, 2020 16:42
@michaelwoerister
Copy link
Member

Something in here has regressed compile times quite a bit:
https://perf.rust-lang.org/compare.html?start=c74353c7d2e61b111a9241490b9fbbd1ebe491fe&end=6d0bb91bcba33a70fae4b0c663fb4403ed78f071&stat=instructions:u

The details view (e.g. here) shows mostly LLVM_module_codegen_emit_obj, codegen_module, and LLVM_module_codegen_make_bitcode taking longer, which makes me think that something here causes more LLVM bitcode to be generated. #67914 seems like the most likely culprit. @Aaron1011, @matthewjasper, @wesleywiser, @oli-obk, do you think that's plausible? Is there anything we can do here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.