Check for union field accesses in THIR unsafeck #85263

syvb · 2021-05-13T14:46:00Z

see also #85259, #83129, rust-lang/project-thir-unsafeck#7

LeSeulArtichaut

The implementation itself looks good to me (though, again, I'm not a reviewer).

I think we should add revisions for existing tests. If we do, we can mark the errors that we don't emit yet as

//[mirunsafeck]~ ERROR
// FIXME(thir-unsafeck)

Unsure though. Anyway I'd want to hear from @nikomatsakis

LeSeulArtichaut · 2021-05-13T16:06:17Z

r? @nikomatsakis

nikomatsakis · 2021-05-13T16:35:26Z

compiler/rustc_mir_build/src/check_unsafety.rs

+                    if adt_def.is_union() {
+                        self.requires_unsafe(expr.span, AccessToUnionField);
+                    }
+                }


Hm, the actual check seems quite a bit more complicated! (cc @RalfJung, who authored those changes)

https://github.com/rust-lang/rust/blob/24379879acc0959e8ae0f3c19d249b3beb278836/compiler/rustc_mir/src/transform/check_unsafety.rs#L214-L266

I'm wondering why more tests didn't fail. I think we're going to have to tweak these rules here.

Oh, right, you need unsafe to read from the union. (Tbh I've never used unions in Rust 😄)

I'm wondering why more tests didn't fail.

~~I think we don't run the existing check-fail tests, see my comment above.~~
EDIT: nevermind, this should be too conservative instead

All reads and some writes should be unsafe, yes -- and we should have tests covering that... tough probably not very precise ones.

Yes, the src/test/ui/union/union-unsafe.rs should help; you probably want to run that under thirunsafeck as well.

@RalfJung I'm trying to properly check if something is reading from a union, and encountered this weirdness. Is this a bug or feature of the MIR borrow checker?

// this is safe match foo { Foo { zst: () } => {}, } // but this is so unsafe it prints the same error message twice? match foo { Foo { pizza: Pizza { topping: Some(PizzaTopping::Cheese) | Some(PizzaTopping::Pineapple) | None } } => {}, // ^~ ERROR access to union field is unsafe and requires unsafe function or block }

playground

I think that behavior in the first match is a bug in the MIR borrowck, since RFC 1444 says that pattern matching against unions must be unsafe. (and MIR borrowck is okay with it since it doesn't actually involve any reads)

I guess this has to do with how pattern matching is compiled -- matching zst against the () pattern does not actually read anything (we know the pattern matches without even looking). So it makes sense to me that the former would not be unsafe. But one could easily decide either way and both ways make sense.

Note that this pattern is unsafe:

Foo { zst: x }

I've updated the checking, I think it should properly detect if something is a read or write to union now (I am also now running almost all of the src/test/ui/union test suite).

compiler/rustc_mir_build/src/check_unsafety.rs

syvb · 2021-05-14T14:53:01Z

The THIR checker now rejects code like this while the MIR checker doesn't. I'm pretty sure that this is a bug with the MIR checker though.

union Foo { bar: i8 }
let Foo { bar: _ } = Foo { bar: 5 };

union Foo2 { bar: () }
let Foo2 { bar: () } = Foo2 { bar: () };

None of those actually do anything though, so it doesn't seem like this would have any real-world implications.

(playground)

RalfJung · 2021-05-14T15:25:45Z

I'm on the fence about whether those should require unsafe or not -- as I said, given that matching against () is quite clearly not actually reading the union field, making this safe seems reasonable to me.

Making them unsafe would be a breaking change, so the question is also if that change is worth it. My inclination here is "no" -- either way is a good option, and so in the absence of a preference either way we should err on the side of not doing a breaking change.

What is the argument for why you consider this a bug in the MIR checker?

syvb · 2021-05-14T16:25:06Z

@RalfJung The MIR rules result in really odd behavior like this in safe code:

#[derive(Copy, Clone)]
#[repr(u8)]
enum OneVal {
    One = 1,
}

union Foo {
    bar: u8,
    oneval: OneVal
}

fn main() {
    match (Foo { bar: 42 }) {
        Foo { oneval: OneVal::One } => {
            println!("reached!"); // always prints
        },
    }
}

The value of Foo isn't 1 and doesn't represent OneVal::One when the first and only branch is reached, but the first arm always matches. (I'm not sure if this is UB) Even weirder, this code does require an unsafe block, even though x is being bound to a constant (OneVal::One):

match (Foo { bar: 42 }) {
    Foo { oneval: x @ OneVal::One } => { //~ ERROR access to union field is unsafe
        println!("reached!");
    },
}

And if we add another field to the enum suddenly even exhaustive matching against it using or patterns is unsafe:

#[derive(Copy, Clone)]
#[repr(u8)]
pub enum TwoVal {
    One = 1,
    Two = 2,
}

union Foo {
    bar: u8,
    oneval: TwoVal
}

fn main() {
    match (Foo { bar: 42 }) {
        Foo { oneval: TwoVal::One | TwoVal::Two } => { //~ ERROR access to union field is unsafe
            println!("reached!");
        },
    }
}

LeSeulArtichaut · 2021-05-14T16:31:14Z

(This is a debate that looks somewhat similar to #80059)

syvb · 2021-05-14T16:43:00Z

That weird behavior is actually a regression. Rust 1.19 (first stable release with unions) rejects the first snippet while Rust 1.22 accepts it.

RalfJung · 2021-05-14T16:48:35Z

I agree the OneVal behavior is surprising and possibly a bug, since OneVal has size 1.

But that does not imply that the () behavior is a bug. If you remove the repr(u8), the behavior you see is what I would expect.

compiler/rustc_mir_build/src/check_unsafety.rs

syvb · 2021-05-14T22:35:41Z

I've loosened up the safety rules a little bit to allow binding union fields to wildcards:

#[derive(Copy, Clone)]
struct Pie {
    slices: u8,
    size: u8,
}

union Foo {
    bar: i8,
    baz: Pie
}

// safe with THIR and MIR checker:
match u {
    Foo { baz: _ } => {},
}

// unsafe to THIR, safe to MIR:
match u {
    Foo { baz: Pie { .. } } => {},
}
match u {
    Foo { baz: Pie { slices: _, size: _ } } => {},
}

bors · 2021-05-16T04:04:54Z

☔ The latest upstream changes (presumably #85259) made this pull request unmergeable. Please resolve the merge conflicts.

syvb · 2021-05-17T00:30:48Z

I've updated the way it checks unsafety to match the MIR rules as closely as possible. Specifically, the rule it enforces is "Irrefutable pattern matching against unions without any bindings is safe". This makes the THIR checker almost entirely match the MIR checker. The only difference I know of is

union Foo { bar: i8, pizza: Pizza }
#[derive(Copy, Clone)]
struct Pizza {
    topping: Option<PizzaTopping>
}
#[derive(Copy, Clone)]
enum PizzaTopping { Cheese, Pineapple }

let foo = Foo { bar: 5 };
match foo { Foo {
    pizza: Pizza {
        topping: Some(PizzaTopping::Cheese) | Some(PizzaTopping::Pineapple) | None
    }
} => {} };

Which the THIR checker accepts but MIR rejects. This seems to be a quirk of the way the MIR desugars nested or expressions.

RalfJung · 2021-05-17T07:31:52Z

"Irrefutable pattern matching against unions without any bindings is safe"

Uh... is that really what the old checker did? "Irrefutable" is a very subtle notion, in particular when considering unions.
The patterns we were talking about, like (), aren't just irrefutable -- they were literally NOPs without even considering the "set of possible values", since two zero-sized values are always equal! Anything that actually matches on a non-zero-sized enum should IMO definitely be unsafe.

syvb · 2021-05-17T11:35:32Z

@RalfJung As far as I can tell that's what's happening. Here's another example:

union Foo { bar: i8 }
let foo = Foo { bar: 5 };
match foo { Foo {
    bar: i8::MIN..=i8::MAX, // safe since this always matches
} => {} };

(playground)

Perhaps it would be better to change to rejecting patterns like this and only make an exception for ZSTs?

RalfJung · 2021-05-17T13:29:14Z

Hm, interesting.
I'm honestly not sure any more what would be better.^^ Looks like T-lang needs to make a decision here about which patterns on union fields should be considered safe and which need unsafe.

…rtichaut Add pattern walking support to THIR walker Suggested in rust-lang#85263 (comment), this splits off the support for pattern walking in THIR from rust-lang#85263. This has no observable effect on THIR unsafety checking, since it is not currently possible to trigger unsafety from the THIR checker using the additional patterns or constants that are now walked. THIR patterns are walked in source code order. r? `@LeSeulArtichaut`

…ichaut Add pattern walking support to THIR walker Suggested in rust-lang#85263 (comment), this splits off the support for pattern walking in THIR from rust-lang#85263. This has no observable effect on THIR unsafety checking, since it is not currently possible to trigger unsafety from the THIR checker using the additional patterns or constants that are now walked. THIR patterns are walked in source code order. r? `@LeSeulArtichaut`

bors · 2021-06-19T08:51:17Z

☔ The latest upstream changes (presumably #86378) made this pull request unmergeable. Please resolve the merge conflicts.

oli-obk · 2021-07-08T11:37:42Z

r? @oli-obk

oli-obk

I just found a small edge case that is probably an unreachable pattern.

The union "drop field" assignment unsafety can be solved in a follow up PR, they are marked with FIXMEs after all.

compiler/rustc_mir_build/src/check_unsafety.rs

oli-obk · 2021-07-09T20:52:38Z

@bors r+

bors · 2021-07-09T20:52:39Z

📌 Commit b86ed4a has been approved by oli-obk

bors · 2021-07-09T20:56:13Z

⌛ Testing commit b86ed4a with merge 240ff4c...

bors · 2021-07-09T23:24:16Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 240ff4c to master...

LeSeulArtichaut · 2021-07-27T18:14:11Z

Moved the discussion about pattern matching on unions to #87520.

rust-highfive assigned LeSeulArtichaut May 13, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 13, 2021

LeSeulArtichaut mentioned this pull request May 13, 2021

Implement the THIR unsafety checker rust-lang/project-thir-unsafeck#7

Closed

13 tasks

LeSeulArtichaut reviewed May 13, 2021

View reviewed changes

rust-highfive assigned nikomatsakis and unassigned LeSeulArtichaut May 13, 2021

nikomatsakis requested changes May 13, 2021

View reviewed changes

syvb force-pushed the thir-unsafeck-union-field branch 2 times, most recently from 7f424a7 to 14834a6 Compare May 14, 2021 13:01

This comment has been minimized.

Sign in to view

syvb force-pushed the thir-unsafeck-union-field branch from 14834a6 to 62bbb23 Compare May 14, 2021 13:43

LeSeulArtichaut reviewed May 14, 2021

View reviewed changes

compiler/rustc_mir_build/src/check_unsafety.rs Outdated Show resolved Hide resolved

RalfJung reviewed May 14, 2021

View reviewed changes

compiler/rustc_mir_build/src/check_unsafety.rs Outdated Show resolved Hide resolved

RalfJung reviewed May 14, 2021

View reviewed changes

compiler/rustc_mir_build/src/check_unsafety.rs Outdated Show resolved Hide resolved

RalfJung reviewed May 14, 2021

View reviewed changes

compiler/rustc_mir_build/src/check_unsafety.rs Show resolved Hide resolved

syvb force-pushed the thir-unsafeck-union-field branch from 42b10ea to 129958e Compare May 14, 2021 22:36

syvb force-pushed the thir-unsafeck-union-field branch from 129958e to e6c63c8 Compare May 16, 2021 14:06

syvb mentioned this pull request Jun 16, 2021

Add pattern walking support to THIR walker #86378

Merged

rust-highfive assigned oli-obk and unassigned nikomatsakis Jul 8, 2021

oli-obk requested changes Jul 9, 2021

View reviewed changes

compiler/rustc_mir_build/src/check_unsafety.rs Outdated Show resolved Hide resolved

syvb added 2 commits July 9, 2021 13:51

Check for union field accesses in THIR unsafeck

74d0d74

Don't stub out part of test

df3e003

syvb force-pushed the thir-unsafeck-union-field branch from 7ab11d2 to df3e003 Compare July 9, 2021 17:51

panic when trying to destructure union as enum

b86ed4a

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 9, 2021

bors merged commit 240ff4c into rust-lang:master Jul 9, 2021

rustbot added this to the 1.55.0 milestone Jul 9, 2021

This was referenced Jul 9, 2021

Stabilize const_fn_transmute, const_fn_union #85769

Merged

Make deleted code in a suggestion clearer #86532

Merged

Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck #86665

Merged

Suggest deriving traits if possible #86943

Merged

LeSeulArtichaut mentioned this pull request Jul 27, 2021

Which patterns on union fields should be considered safe? #87520

Open

LeSeulArtichaut removed I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jul 27, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Check for union field accesses in THIR unsafeck #85263

Check for union field accesses in THIR unsafeck #85263

syvb commented May 13, 2021

LeSeulArtichaut left a comment

LeSeulArtichaut commented May 13, 2021

nikomatsakis May 13, 2021

LeSeulArtichaut May 13, 2021 •

edited

Loading

RalfJung May 13, 2021

RalfJung May 13, 2021

syvb May 13, 2021

syvb May 13, 2021

RalfJung May 14, 2021 •

edited

Loading

RalfJung May 14, 2021

syvb May 14, 2021

This comment has been minimized.

syvb commented May 14, 2021 •

edited

Loading

RalfJung commented May 14, 2021 •

edited

Loading

syvb commented May 14, 2021

LeSeulArtichaut commented May 14, 2021

syvb commented May 14, 2021

RalfJung commented May 14, 2021

syvb commented May 14, 2021

bors commented May 16, 2021

syvb commented May 17, 2021

RalfJung commented May 17, 2021 •

edited

Loading

syvb commented May 17, 2021

RalfJung commented May 17, 2021 •

edited

Loading

bors commented Jun 19, 2021

oli-obk commented Jul 8, 2021

oli-obk left a comment

oli-obk commented Jul 9, 2021

bors commented Jul 9, 2021

bors commented Jul 9, 2021

bors commented Jul 9, 2021

LeSeulArtichaut commented Jul 27, 2021

Check for union field accesses in THIR unsafeck #85263

Check for union field accesses in THIR unsafeck #85263

Conversation

syvb commented May 13, 2021

LeSeulArtichaut left a comment

Choose a reason for hiding this comment

LeSeulArtichaut commented May 13, 2021

nikomatsakis May 13, 2021

Choose a reason for hiding this comment

LeSeulArtichaut May 13, 2021 • edited Loading

Choose a reason for hiding this comment

RalfJung May 13, 2021

Choose a reason for hiding this comment

RalfJung May 13, 2021

Choose a reason for hiding this comment

syvb May 13, 2021

Choose a reason for hiding this comment

syvb May 13, 2021

Choose a reason for hiding this comment

RalfJung May 14, 2021 • edited Loading

Choose a reason for hiding this comment

RalfJung May 14, 2021

Choose a reason for hiding this comment

syvb May 14, 2021

Choose a reason for hiding this comment

This comment has been minimized.

syvb commented May 14, 2021 • edited Loading

RalfJung commented May 14, 2021 • edited Loading

syvb commented May 14, 2021

LeSeulArtichaut commented May 14, 2021

syvb commented May 14, 2021

RalfJung commented May 14, 2021

syvb commented May 14, 2021

bors commented May 16, 2021

syvb commented May 17, 2021

RalfJung commented May 17, 2021 • edited Loading

syvb commented May 17, 2021

RalfJung commented May 17, 2021 • edited Loading

bors commented Jun 19, 2021

oli-obk commented Jul 8, 2021

oli-obk left a comment

Choose a reason for hiding this comment

oli-obk commented Jul 9, 2021

bors commented Jul 9, 2021

bors commented Jul 9, 2021

bors commented Jul 9, 2021

LeSeulArtichaut commented Jul 27, 2021

LeSeulArtichaut May 13, 2021 •

edited

Loading

RalfJung May 14, 2021 •

edited

Loading

syvb commented May 14, 2021 •

edited

Loading

RalfJung commented May 14, 2021 •

edited

Loading

RalfJung commented May 17, 2021 •

edited

Loading

RalfJung commented May 17, 2021 •

edited

Loading