tests: Simplify VaList run-make test

[dlrobertson]

The va_list tests were too complex and were causing some spurious
test failures on Windows.

Example: #55011 (comment)

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[nikic]

It's not obvious to me why the previous implementation is triggering assertions. struct Answer is #[repr(C)], so I would expect this to guarantee that the alignment matches on the Rust and the C side.

[nikic]

Okay, I get it now. Turns out that MSVC on x86-32 uses 4-byte stack alignment. Even though the alignment of the structure (in the sense of _Alignof()) is higher, it may still only be 4-byte alignment on the stack, unless you explicitly specify __declspec(align(N)).

[nikic]

If this fails, this would panic across an FFI boundary, which is UB. Not expected to happen, but doing something more conservative (return false / abort) would be better.

[alexcrichton]

FWIW this'll soon become a deterministic abort (not UB), so this is probably fine to leave in

[alexcrichton]

@bors: r=nikic p=10

(hopefully fixing spurious failures!)

[bors]

📌 Commit 28ca35f has been approved by nikic

[bors]

⌛ Testing commit 28ca35f with merge af7554d...

[dlrobertson]

Okay, I get it now. Turns out that MSVC on x86-32 uses 4-byte stack alignment. Even though the alignment of the structure (in the sense of _Alignof()) is higher, it may still only be 4-byte alignment on the stack, unless you explicitly specify __declspec(align(N)).

Exactly. Didn't compile locally with debug_assertions or think of this when I first wrote the test.

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikic
Pushing af7554d to master...