Revert "msvc: Enable landing pads by default" #26919
Conversation
This reverts commit f9de964. Conflicts: src/librustc_trans/trans/base.rs
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @brson |
|
@bors r+ |
|
📌 Commit 813cfa5 has been approved by |
|
⌛ Testing commit 813cfa5 with merge 56e1c47... |
|
💔 Test failed - auto-linux-32-opt |
|
@bors: retry On Thu, Jul 9, 2015 at 1:46 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 813cfa5 with merge 3c935f8... |
|
💔 Test failed - auto-linux-32-opt |
|
@bors: retry On Thu, Jul 9, 2015 at 2:37 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 813cfa5 with merge 3030138... |
|
💔 Test failed - auto-win-gnu-64-nopt-t |
|
@bors: retry On Thu, Jul 9, 2015 at 2:50 PM, bors notifications@github.com wrote:
|
There are a number of problems with MSVC landing pads today: * They only work about 80% of the time with optimizations enabled. For example when running the run-pass test suite a failing test will cause `compiletest` to segfault (b/c of a thread panic). There are also a large number of run-fail tests which will simply crash. * Enabling landing pads caused the regression seen in #26915. Overall it looks like LLVM's support for MSVC landing pads isn't as robust as we'd like for now, so let's take a little more time before we turn them on by default. Closes #26915
There are a number of problems with MSVC landing pads today:
compiletestto segfault (b/c of a thread panic). There are also a large number of run-fail tests which will simply crash.Overall it looks like LLVM's support for MSVC landing pads isn't as robust as we'd like for now, so let's take a little more time before we turn them on by default.
Closes #26915