-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
[beta] backport rollup #65708
[beta] backport rollup #65708
Conversation
…crichton Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux rust-lang#62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9. This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux. Fixes rust-lang#62896 r? @alexcrichton
This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example, in rust-lang#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct, but no tests seem to fail as a result of this change in local testing.
…king-rust-abi-unwind-issue-64655, r=alexcrichton Always mark rust and rust-call abi's as unwind PR rust-lang#63909 identified a bug that had been injected by PR rust-lang#55982. As discussed on rust-lang#64655 (comment) , we started marking extern items as nounwind, *even* extern items that said they were using "Rust" or "rust-call" ABI. This is a more targeted variant of PR rust-lang#63909 that fixes the above bug. Fix rust-lang#64655 ---- I personally suspect we will want PR rust-lang#63909 to land in the long-term But: * it is not certain that PR rust-lang#63909 *will* land, * more importantly, PR rust-lang#63909 almost certainly will not be backported to beta/stable. The identified bug was more severe than I think anyone realized (apart from perhaps @gnzlbg, as noted [here](rust-lang#63909 (comment))). Thus, I was motivated to write this PR, which fixes *just* the issue with extern rust/rust-call functions, and deliberately avoids injecting further deviation from current behavior (you can see further notes on this in the comments of the code added here).
This commit silences the unreachable code lint when it originates from within a await desugaring. Signed-off-by: David Wood <[email protected]>
@bors r+ p=8 |
📌 Commit c38b91c has been approved by |
@bors rollup=never just in case |
⌛ Testing commit c38b91c with merge 56a72c3ed96447a73df0b06a5507ada48edf6a66... |
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
@bors retry network failure |
⌛ Testing commit c38b91c with merge f845822d08d5519fc59792140ad25d00936ad8e5... |
💔 Test failed - checks-azure |
Co-Authored-By: Pietro Albini <[email protected]>
…, r=petrochenkov" This reverts commit ef1ecbe, reversing changes made to fc8765d. That changed unfortunately broke rustfix on windows: rust-lang/rustfix#176 Specifically, what ef1ecbe did was to enforce normalization of \r\n to \n at file loading time, similarly to how we deal with Byte Order Mark. Normalization changes raw offsets in files, which are exposed via `--error-format=json`, and used by rusfix. The proper solution here (which also handles the latent case with BOM) is rust-lang#65074 However, since it's somewhat involved, and we are time sensitive, we prefer to revert the original change on beta.
d685e25
to
4aa1e7a
Compare
@bors r=pietroalbini |
📌 Commit 4aa1e7a has been approved by |
⌛ Testing commit 4aa1e7a with merge a208771ff518647d885c9529e3cfac0a26ed3d10... |
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
@bors retry
|
[beta] backport rollup This includes a bunch of PRs: * Fix redundant semicolon lint interaction with proc macro attributes #64387 * Upgrade async/await to "used" keywords. #64875 * syntax: fix dropping of attribute on first param of non-method assocated fn #64894 * async/await: improve not-send errors #64895 * Silence unreachable code lint from await desugaring #64930 * Always mark rust and rust-call abi's as unwind #65020 * Account for macro invocation in `let mut $pat` diagnostic. #65123 * Ensure that associated `async fn`s have unique fresh param names #65142 * Add troubleshooting section to PGO chapter in rustc book. #65402 * Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302 * Optimize `try_expand_impl_trait_type` #65293 * use precalculated dominators in explain_borrow #65172 * Fix ICE #64964 #64989 * [beta] Revert "Auto merge of #62948 - matklad:failable-file-loading, r=petro… #65273 * save-analysis: Don't ICE when resolving qualified type paths in struct members #65353 * save-analysis: Nest tables when processing impl block definitions #65511 * Avoid ICE when checking `Destination` of `break` inside a closure #65518 * Avoid ICE when adjusting bad self ty #65755 * workaround msys2 bug #65762
☀️ Test successful - checks-azure |
This includes a bunch of PRs:
let mut $pat
diagnostic. Account for macro invocation inlet mut $pat
diagnostic. #65123async fn
s have unique fresh param names Ensure that associatedasync fn
s have unique fresh param names #65142try_expand_impl_trait_type
Optimizetry_expand_impl_trait_type
#65293StableHasher: unexpected region '_#0r
) #64964 Fix ICE #64964 #64989Destination
ofbreak
inside a closure Avoid ICE when checkingDestination
ofbreak
inside a closure #65518