Uh oh!
There was an error while loading. Please reload this page.
Rollup of 9 pull requests - #48652
Merged
Merged
Conversation
The *.md at the root directory in src/doc are no longer tested, but this should be fine since all files there are deprecated.
Commit 0bd9667 added bounds checking of our current target byte position to prevent infinite loops. Unfortunately it was comparing the file-relative `target` versus the global relative `file_start_pos` and `file_end_pos`. The result is failing to detect multibyte characters unless their file-relative offset fit within their global offset. This causes other parts of the compiler to generate spans pointing to the middle of a multibyte character which will ultimately panic in `bytepos_to_file_charpos`. Fix by comparing the `target` to the total file size when moving forward and doing checked subtraction when moving backwards. This should preserve the intent of the bounds check while removing the offset confusion. Fixesrust-lang#48508
This is named for the issue as it's testing the specific details of that bug. It's a bit tricky as the ICE requires multiple files and debug info enabled to trigger.
It isn't a valid LLVM feature for this architecture.
This commit is targeted at addressing rust-lang#48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in rust-lang#46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than rust-lang#48567 and should help us stick to standard personality functions a bit longer.
Improve recovery for trailing comma after `..`
The out-of-line module rust-lang#37195
…Mark-Simulacrum Auto-toolstate management follow-up. Tracking comment: rust-lang#45861 (comment) * Fixedrust-lang-nursery/rust-toolstate#1, a proper link to the PR will be included. * Fixedrust-lang-nursery/rust-toolstate#2, a comment will be posted to the PR if the toolstate changed * Toolstate regression will be rejected at the last week of the 6-week cycle (currently entirely date-based). * Implemented https://internals.rust-lang.org/t/the-current-submodule-setup-is-not-tenable/6593, moved doc tests of Nomicon, Reference, Rust-by-Example and The Book to the "tools" job and thus allowed to fail like other external tools.
Remove E0245; improve E0404 Fixrust-lang#36337 Somehow this is currently breaking --explain, but I don't understand how. r? @estebank
Support parentheses in patterns under feature gate This is a prerequisite for any other extensions to pattern syntax - `|` with multiple patterns, type ascription, `..PAT` in slice patterns. Closesrust-lang/rfcs#554
…-at-span-bounds-check, r=estebank Fix find_width_of_character_at_span bounds check Commit 0bd9667 added bounds checking of our current target byte position to prevent infinite loops. Unfortunately it was comparing the file-relative `target` versus the global `file_start_pos` and `file_end_pos`. The result is failing to detect multibyte characters unless their file-relative offset fit within their global offset. This causes other parts of the compiler to generate spans pointing to the middle of a multibyte character which will ultimately panic in `bytepos_to_file_charpos`. Fix by comparing the `target` to the total file size when moving forward and doing checked subtraction when moving backwards. This should preserve the intent of the bounds check while removing the offset confusion. cc @davidtwcoFixesrust-lang#48508
rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing rust-lang#48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in rust-lang#46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than rust-lang#48567 and should help us stick to standard personality functions a bit longer.
…h, r=alexcrichton Stabilize LocalKey::try_with The `LocalKey::try_with` method is now stabilized. `LocalKey::state` and `LocalKeyState` marked as deprecated. Although, is there any reason to keep them - should we perhaps remove them completely? Closesrust-lang#27716 r? @alexcrichton
…, r=nikomatsakis Add regression test for rust-lang#48551 [Issue link](rust-lang#48551)
Fix link to rustc guide in README.md This is a follow-up to rust-lang#48479 and fixes a minor bug with the link to the rustc guide in the README. r? @nikomatsakis cc @mark-i-m
…chton Add AArch64 features to whitelist
bors
commented
Mar 2, 2018
Collaborator
📌 Commit 59937bb has been approved by |
Manishearth
commented
Mar 2, 2018
MemberAuthor
@bors r+ p=10 |
bors
commented
Mar 2, 2018
Collaborator
📌 Commit 2b3c815 has been approved by |
bors
commented
Mar 2, 2018
Collaborator
⌛ Testing commit 2b3c815 with merge 9d3360bd784246cbba8c8ebe925d8bb376405417... |
Merged
bors
commented
Mar 2, 2018
Collaborator
💔 Test failed - status-travis |
Manishearth
commented
Mar 2, 2018
MemberAuthor
@bors retry timeout |
bors
commented
Mar 2, 2018
Collaborator
bors
commented
Mar 2, 2018
Collaborator
💥 Test timed out |
Manishearth
commented
Mar 2, 2018
MemberAuthor
@bors r- you confused |
kennytm
commented
Mar 3, 2018
Member
@bors clean retry r- |
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
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.
Uh oh!
There was an error while loading. Please reload this page.