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 11 pull requests #49924

Closed
wants to merge 30 commits into from
Closed

Rollup of 11 pull requests #49924

wants to merge 30 commits into from

Conversation

kennytm
Copy link
Member

@kennytm kennytm commented Apr 13, 2018

Successful merges:

Failed merges:

varkor and 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
Collaborator

r? @michaelwoerister

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

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

kennytm commented Apr 13, 2018

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Apr 13, 2018

📌 Commit 1ea2014 has been approved by kennytm

@bors bors 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
@kennytm kennytm changed the title Rollup of 10 pull requests Rollup of 11 pull requests Apr 13, 2018
@kennytm
Copy link
Member Author

kennytm commented Apr 13, 2018

@bors r+ p=11

Added #49916.

@bors
Copy link
Contributor

bors commented Apr 13, 2018

📌 Commit f1a38ab has been approved by kennytm

@ishitatsuyuki
Copy link
Contributor

Maybe you can roll up #49800 too?

@kennytm kennytm changed the title Rollup of 11 pull requests Rollup of 12 pull requests Apr 13, 2018
@kennytm
Copy link
Member Author

kennytm commented Apr 13, 2018

@bors r+

Added #49289.

@bors
Copy link
Contributor

bors commented Apr 13, 2018

📌 Commit 00f36b1 has been approved by kennytm

@kennytm
Copy link
Member Author

kennytm commented Apr 13, 2018

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

@kennytm kennytm changed the title Rollup of 12 pull requests Rollup of 11 pull requests Apr 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

Fixes rust-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
Member Author

kennytm commented Apr 13, 2018

@bors r+

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

@bors
Copy link
Contributor

bors commented Apr 13, 2018

📌 Commit f1da9f4 has been approved by kennytm

@bors
Copy link
Contributor

bors commented Apr 13, 2018

🔒 Merge conflict

@bors bors 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
Copy link
Contributor

bors commented Apr 13, 2018

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

@kennytm kennytm closed this Apr 13, 2018
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: 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.