Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add reftest that checks the layout of repr(int) on non-c-like enums #45688

Merged
merged 1 commit into from
Nov 9, 2017

Conversation

Gankra
Copy link
Contributor

@Gankra Gankra commented Nov 1, 2017

This verifies the first layout specified in rust-lang/rfcs#2195

The second (repr(C)) layout isn't included here because it doesn't actually exist today. However if/when that's implemented a second test could be fairly easily derived from this one.

CC @eddyb

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

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

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 1, 2017
@alexcrichton
Copy link
Member

@bors: r+

Nice!

@bors
Copy link
Contributor

bors commented Nov 1, 2017

📌 Commit 95a7f29 has been approved by alexcrichton

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 1, 2017
@bors
Copy link
Contributor

bors commented Nov 3, 2017

⌛ Testing commit 95a7f29 with merge 8df508c...

bors added a commit that referenced this pull request Nov 3, 2017
Add reftest that checks the layout of repr(int) on non-c-like enums

This verifies the first layout specified in rust-lang/rfcs#2195

The second (`repr(C)`) layout isn't included here because it doesn't actually exist today. However if/when that's implemented a second test could be fairly easily derived from this one.

CC @eddyb
@bors
Copy link
Contributor

bors commented Nov 3, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Nov 3, 2017

x86_64-gnu-aux, pretty test failed, legit.

[01:22:58] ---- [pretty] run-pass/enum-non-c-like-repr-int.rs stdout ----
[01:22:58] 	
[01:22:58] error: pretty-printed source does not match expected source
<snip>

The diff:

--- 1.txt	2017-11-03 15:20:03.000000000 +0800
+++ 2.txt	2017-11-03 15:20:16.000000000 +0800
@@ -75,8 +75,10 @@
 [01:22:58]     let input: Vec<u8> =
 [01:22:58]         vec!(0 , 17 , 0 , 0 , 0 , 1 , 206 , 121 , 4 , 2 , 8 , 3 , 0 , 151 , 1
 [01:22:58]              , 0 , 0 , 3 , 1 , 4 , 100 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0
-[01:22:58]              , 0 , 0 ,); // Invalid tag value
-[01:22:58]     // Incomplete value
+[01:22:58]              , 0 , 0
+[01:22:58]              ,); // Invalid tag value
+[01:22:58]                  // Incomplete value
+[01:22:58] 
 [01:22:58] 
 [01:22:58]     let mut output = vec!();
 [01:22:58]     let mut buf = &input[..];

(1.txt is "expected", 2.txt is "actual")

You could run this test with

./x.py test src/test/run-pass/pretty --test-args enum-non-c-like-repr-int

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 3, 2017
}

fn parse_my_enum<'a>(dest: &'a mut MyEnum, buf: &mut &[u8]) -> Result<(), ()> {
unsafe {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth to limit this unsafe block only to transmute instruction? (doesn't look like anything else in the function needs it)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All union accesses are unsafe, afaik

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gankro Writing to a union doesn't require unsafe block, only reading does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the union at the start of the match, and if we're being honest, writing to the unions is Pretty Unsafe. It's just not unsafe for rules-lawyer reasons.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gankro Writing to unions just puts contents into Schrodinger's state - they might or might be not corrupt until you try to read them 😄

@Gankra
Copy link
Contributor Author

Gankra commented Nov 8, 2017

Tidy fixed.

@kennytm
Copy link
Member

kennytm commented Nov 8, 2017

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Nov 8, 2017

📌 Commit e156f89 has been approved by alexcrichton

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 8, 2017
@bors
Copy link
Contributor

bors commented Nov 9, 2017

⌛ Testing commit e156f89 with merge fc77b62...

bors added a commit that referenced this pull request Nov 9, 2017
Add reftest that checks the layout of repr(int) on non-c-like enums

This verifies the first layout specified in rust-lang/rfcs#2195

The second (`repr(C)`) layout isn't included here because it doesn't actually exist today. However if/when that's implemented a second test could be fairly easily derived from this one.

CC @eddyb
@bors
Copy link
Contributor

bors commented Nov 9, 2017

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

@bors bors merged commit e156f89 into rust-lang:master Nov 9, 2017
petertodd added a commit to petertodd/rust that referenced this pull request Dec 8, 2018
RFC rust-lang#2195 specifies that a repr(int) enum such as:

    #[repr(u8)]
    enum MyEnum {
        B { x: u8, y: i16, z: u8 },
    }

has a layout that is equivalent to:

    #[repr(C)]
    enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },

However this isn't actually implemented, with the actual layout being
roughly equivalent to:

    union MyEnumPayload {
        B { x: u8, y: i16, z: u8 },
    }

    #[repr(packed)]
    struct MyEnum {
        tag: u8,
        payload: MyEnumPayload,
    }

Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`

The existing tests added in pull-req rust-lang#45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
emilio pushed a commit to emilio/rust that referenced this pull request Dec 16, 2018
RFC rust-lang#2195 specifies that a repr(int) enum such as:

    #[repr(u8)]
    enum MyEnum {
        B { x: u8, y: i16, z: u8 },
    }

has a layout that is equivalent to:

    #[repr(C)]
    enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },

However this isn't actually implemented, with the actual layout being
roughly equivalent to:

    union MyEnumPayload {
        B { x: u8, y: i16, z: u8 },
    }

    #[repr(packed)]
    struct MyEnum {
        tag: u8,
        payload: MyEnumPayload,
    }

Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`

The existing tests added in pull-req rust-lang#45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants