Skip to content

Rollup of 11 pull requests - #49924

Closed
kennytm wants to merge 30 commits into
rust-lang:masterfrom
kennytm:rollup
Closed

Rollup of 11 pull requests#49924
kennytm wants to merge 30 commits into
rust-lang:masterfrom
kennytm:rollup

Conversation

@kennytm

@kennytmkennytm commented Apr 13, 2018

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

varkorand others added 27 commits March 22, 2018 23:58
Previously, generate-deriving-span-tests.py would regenerate all the tests anew, even if they hadn't changed. This creates unnecessary diffs that only change the copyright year. Now we check to see if any of the content of the test has changed before generating the new one.
`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!
As a result this commit makes the following tweaks:
* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
`Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
indicating that the function call couldn't panic wasn't quite right in that if
`alloc_size` becomes too large and if `align` is high enough it could indeed
cause a panic.
This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
…oerister
Make OnDiskCache thread-safer
I'm not sure if `synthetic_expansion_infos` is handled correctly.
`interpret_alloc_cache` and `interpret_alloc_size` seems to be wrong though, since the code may now decode two `AllocId`s in parallel. I'd like some input on how to fix that.
cc @oli-obk
r? @michaelwoerister
Implement Chalk lowering rule Normalize-From-Impl
This extends the Chalk lowering pass with the "Normalize-From-Impl" rule for generating program clauses from a trait definition as part of rust-lang#49177.
r? @nikomatsakis
…r=alexcrichton
Cross-compile builder to Windows for PRs on Travis
I chose a completely arbitrary windows target here (I have no idea what's best, we could do multiple -- they are relatively fast).
r? @alexcrichton
…☹, r=nrc
Don't inject clippy into rls on stable/beta
r? @nrc
as discussed at the all-hands
…mulacrum
core: Remove panics from some `Layout` methods
`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!
As a result this commit makes the following tweaks:
* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
`Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
indicating that the function call couldn't panic wasn't quite right in that if
`alloc_size` becomes too large and if `align` is high enough it could indeed
cause a panic.
This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
…-usability, r=nikomatsakis
Ignore copyright year when generating deriving span tests
Previously, generate-deriving-span-tests.py would regenerate all the tests anew, even if they hadn't changed. This creates unnecessary diffs that only change the copyright year. Now we check to see if any of the content of the test has changed before generating the new one.
…lexcrichton
Work around LLVM debuginfo problem in librustc_driver.
Works around a problem (rust-lang#48910) with global variable debuginfo generation for `rustc_driver::get_trans::LOAD` by applying `#[no_debug]` to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.
Since the problem is also present in beta, this workaround might have to be backported.
r? @alexcrichton
…st-without-rpath, r=Mark-Simulacrum
Fix test failure in src/tools/rustdoc-themes when rust.rpath = false
See rust-lang#49907
@rust-highfive

Copy link
Copy Markdown
Contributor

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 13, 2018
@kennytm

Copy link
Copy Markdown
MemberAuthor

@bors r+ p=10

@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

📌 Commit 1ea2014 has been approved by kennytm

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 13, 2018
@kennytmkennytm changed the title Rollup of 10 pull requestsRollup of 11 pull requestsApr 13, 2018
@kennytm

Copy link
Copy Markdown
MemberAuthor

@bors r+ p=11

Added #49916.

@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

📌 Commit f1a38ab has been approved by kennytm

@ishitatsuyuki

Copy link
Copy Markdown
Contributor

Maybe you can roll up #49800 too?

@kennytmkennytm changed the title Rollup of 11 pull requestsRollup of 12 pull requestsApr 13, 2018
@kennytm

Copy link
Copy Markdown
MemberAuthor

@bors r+

Added #49289.

@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

📌 Commit 00f36b1 has been approved by kennytm

@kennytm

Copy link
Copy Markdown
MemberAuthor

@ishitatsuyuki Sorry I think the change introduced by #49800 is pretty complex, so I intend not to roll this up.

@kennytmkennytm changed the title Rollup of 12 pull requestsRollup of 11 pull requestsApr 13, 2018
…ennytm
improve Atomic*::fetch_update docs
This clarifies that fetch_update *always* returns the previous value, either as `Ok(_)` or `Err(_)`, depending on whether the supplied update function returned `Some(_)` or `None`.
…r=michaelwoerister
Make --emit=metadata output metadata regardless of link
Fixesrust-lang#40109. I'm not sure whether this condition was important here or not, but I can't see why it is required (removing it doesn't cause the error the comment warns about, so I'm assuming it's safe). If this is too heavy-handed, I can special-case on `OutputType::Metadata`.
@kennytm

Copy link
Copy Markdown
MemberAuthor

@bors r+

Removed #49915 (PR may need to be changed).

@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

📌 Commit f1da9f4 has been approved by kennytm

@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

🔒 Merge conflict

@borsbors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 13, 2018
@bors

bors commented Apr 13, 2018

Copy link
Copy Markdown
Collaborator

☔ The latest upstream changes (presumably #49669) made this pull request unmergeable. Please resolve the merge conflicts.

@kennytmkennytm closed this Apr 13, 2018
@CentrilCentril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-authorStatus: This is awaiting some action (such as code changes or more information) from the author.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

15 participants

@kennytm@rust-highfive@bors@ishitatsuyuki@Centril@michaelwoerister@varkor@fanzier@oli-obk@alexcrichton@chrisccoulson@Mark-Simulacrum@Zoxc@llogiq@f-bro