Rollup of 11 pull requests #49924
Closed
Rollup of 11 pull requests #49924
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ p=10 |
|
📌 Commit 1ea2014 has been approved by |
bors
added
S-waiting-on-bors
|
📌 Commit f1a38ab has been approved by |
|
Maybe you can roll up #49800 too? |
|
📌 Commit 00f36b1 has been approved by |
|
@ishitatsuyuki Sorry I think the change introduced by #49800 is pretty complex, so I intend not to roll this up. |
Remove -Zmiri debugging option ?r @oli-obk
…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`.
|
📌 Commit f1da9f4 has been approved by |
|
🔒 Merge conflict |
bors
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #49669) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Layoutmethods #49884 (core: Remove panics from someLayoutmethods)Failed merges: