Respect endianness correctly in CheckEnums test suite #143339
Conversation
rustbot
added
A-compiletest
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
|
☔ The latest upstream changes (presumably #143337) made this pull request unmergeable. Please resolve the merge conflicts. |
We already have //@ ignore-endian-big, this does the same for little endian.
The endianness can change the test expectation for the enum check. This change is correcting these expectations and adds separate tests for big endian targets with the correct expectations.
| @@ -1,5 +1,8 @@ | |||
| //@ run-fail | |||
| //@ compile-flags: -C debug-assertions | |||
| // This test depends on the endianess and has a different behavior on | |||
| // big endian. | |||
| //@ ignore-endian-big | |||
| //@ error-pattern: trying to construct an enum from an invalid value 0x10000 | |||
There was a problem hiding this comment.
instead of splitting this test, consider using revisions and keeping the old name?
There was a problem hiding this comment.
search for existing //@ revisions to see how it works
There was a problem hiding this comment.
Or better, use cfg to make the code work under little-endian and big-endian.
| @@ -1,5 +1,8 @@ | |||
| //@ run-pass | |||
| //@ compile-flags: -C debug-assertions | |||
| // This test depends on the endianess and has a different behavior on | |||
| // big endian. | |||
| //@ ignore-endian-big | |||
| @@ -1,5 +1,8 @@ | |||
| //@ run-fail | |||
| //@ compile-flags: -C debug-assertions | |||
| // This test depends on the endianess and has a different behavior on | |||
| // big endian. | |||
| //@ ignore-endian-big | |||
| //@ error-pattern: trying to construct an enum from an invalid value 0x3 | |||
|
@rustbot author |
rustbot
added
S-waiting-on-author
There was a problem hiding this comment.
Why does this test use a struct with two u16 fields to begin with? if you transmuted a u32 directly to Foo, things would be endian-independent. (same for convert_non_enum_break)
There was a problem hiding this comment.
What is endian-dependent about this test?
There was a problem hiding this comment.
Why should this pass on big-endian? That makes no sense, it's still an invalid enum!
There was a problem hiding this comment.
Oh I think I see what happens... Foo becomes a 1-byte enum and 3 in big-endian leaves that byte 0, and only changes the padding.
The test should be made endian-independent by adding repr(u32) to Foo and by having Bar with two u32 fields:
#[allow(dead_code)]
#[repr(u32)]
enum Foo {
A,
B,
}
#[allow(dead_code)]
struct Bar {
a: u32,
b: u32,
}
fn main() {
let _val: Option<(u32, Foo)> =
unsafe { std::mem::transmute::<_, Option<(u32, Foo)>>(Bar { a: 3, b: 3 }) };
}
There was a problem hiding this comment.
Replace 4 by u32::MAX here, then the test fails both under little-endian and big-endian.
| @@ -0,0 +1,23 @@ | |||
| //@ run-fail | |||
There was a problem hiding this comment.
A test called ok that is "run-fail" doesn't make a lot of sense, does it?
The endianness can change the test expectation for the enum check. This change is correcting these expectations and adds separate tests for big endian targets with the correct expectations.
Fixes #143332.