-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[MIR] Implement extern call support #30845
Conversation
LGTM. 👍 |
@bors r+ |
📌 Commit dd53fa3 has been approved by |
} | ||
|
||
#[rustc_mir] | ||
fn test10(i: i32, j: i32, k: i32) -> Vec<raw::c_char> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So… this test seems to cause STATUS_HEAP_CORRUPTION on Windows… Hmm.
@bors r- The test causes some sort of heap corruption on Windows. |
Testing that test in the x86_64 msvc nightly without the |
dd53fa3
to
54af95a
Compare
@bors try |
Supersedes #30517 Fixes #29575 cc @luqmana r? @nikomatsakis
54af95a
to
38bed95
Compare
@bors try- (we have no MSVC try bots) |
@bors r=nikomatsakis (adjusted the test with MSVC workarounds, sending to buildbot to see how it goes this time around) |
📌 Commit 38bed95 has been approved by |
@bors retry force |
@bors r- try- r=nmatsakis retry force p=1 38bed95 Hmm. |
📌 Commit 38bed95 has been approved by |
⌛ Testing commit 38bed95 with merge eaa5059... |
💔 Test failed - auto-win-msvc-64-opt |
The reason has been narrowed down. The original trans also fails to translate that test, as has been shown by #30921 and its result. |
Okay, so the reason ends up being |
edbf99f
to
627b886
Compare
I couldn’t reproduce the original failure with VS2013-based rustc locally – the test runs, produces expected results and quits successfully. In the current iteration, the test is disabled on msvc (just like the regular-trans variadic-ffi) and the PR should pass through build bots this time. That being said, the original error is still unsettling and I would like to try sending re-enabled test over to msvc bots again. Is that fine? (Trivia: I once had encountered a SIGSEGV on a unix builder, which turned out to be spurious, before, so the original failure could also be spurious in some way? /me shrugs) |
OK
OK -- do you want to land this PR, then open another that re-enables the test? We can also use the try bots, in that case. |
I think what I’d like to do is try to land this with the test enabled now, and then, provided this PR manages to land, disable it for MSVC in a follow-up PR. The test has to stay disabled, because otherwise it will break everybody’s MSVC-2015-based setups (remember, in that particular version of MSVC sprintf does not exist as a function). Does that sound good to you? |
259a483
to
da3bfa0
Compare
da3bfa0
to
99e8b4d
Compare
Upon suggestion of @dotdash I changed the test to use our own variadic function (defined inside rt/rust_test_helpers.c) instead so we don’t have to worry about the MSVC strangeness. |
@bors r+ |
📌 Commit 99e8b4d has been approved by |
Supersedes #30517 Fixes #29575 cc @luqmana r? @nikomatsakis
Supersedes #30517
Fixes #29575
cc @luqmana
r? @nikomatsakis