Implement untagged unions (RFC 1444) #36016

petrochenkov · 2016-08-26T16:32:36Z

Notes:

The RFC doesn't talk about #[packed] unions, this implementation supports them, packing changes union's alignment to 1 and removes trailing padding.
The RFC doesn't talk about dynamically sized unions, this implementation doesn't support them and rejects them during wf-checking (similarly, dynamically sized enums are not supported as well).
The lint for drop fields in unions can't work precisely before monomorphization, so it works pessimistically - non-Copy generic fields are reported, types not implementing Drop directly, but having non-trivial drop code are reported.
```
struct S(String); // Doesn't implement `Drop`
union U<T> {
    a: S, // Reported
    b: T, // Reported
}
```
Remove the old AST-based backend from rustc_trans. #35764 was indeed helpful and landed timely, I didn't have to implement internal drop flags for unions.
Unions are not permitted in constant patterns, because matching on union fields is unsafe, I didn't want unsafety checker to dig into all constants to uncover this possible unsafety.
The RFC doesn't talk about #[derive], generally trait impls cannot be derived for unions, but some of them can. I implemented only #[derive(Copy)] so far. In theory shallow #[derive(Clone)] can be derived as well if all union fields are Copy, I left it for later though, it requires changing how Clone impls are generated.
Moving union fields is implemented as per Untagged unions (tracking issue for RFC 1444) #32836 (comment).
Testing strategy: union specific behavior is tested, sometimes very basically (e.g. debuginfo), behavior common for all ADTs (e.g. something like coherence
checks) is not generally tested.

petrochenkov · 2016-08-26T18:15:44Z

Actually, I'd like to make the implementation a bit more conservative, than written in the RFC.
Namely, to replace the unions_with_drop_fields lint with a hard error and require user-defined Drop implementation for unions with potentially non-trivially destructible fields (i.e. the same thing C++ does).

Effectively, #[allow(unions_with_drop_fields)] is replaced with impl Drop for U { fn drop(&mut self) {} } in code wanting to use such unions.

eddyb · 2016-08-26T18:22:35Z

src/librustc_mir/build/expr/as_rvalue.rs

@@ -181,6 +181,9 @@ impl<'a, 'gcx, 'tcx> Builder<'a, 'gcx, 'tcx> {
            ExprKind::Adt {
                adt_def, variant_index, substs, fields, base
            } => { // see (*) above
+                let is_union = adt_def.adt_kind() == ty::AdtKind::Union;
+                let active_field_index = if is_union { Some(fields[0].name.index()) } else { None };
+


It might be a better idea to use direct assignment here instead of an Rvalue - that would remove the need to change AggregateKind::Adt - alternatively, an Union AggregateKind could be added.

alternatively, an Union AggregateKind could be added

IIRC, I tried this and didn't like the result (too much common boilerplate code for Adt and Union)

The field assignment approach might be best then.

Not sure what it means exactly. Any example?

Instead of lvalue = union { f: operand } you'd have lvalue.f = operand.

Just realized that could make { let u: Union; u.f = x; u } pass a future MIR move checker - do we want that?

Future move checker with full support for fragments should accept both { let u: Union; u.f = x; u } and { let s: StructWith1Field; s.f = x; s } I guess, see the last item in #36016 (comment) and "# Future work" in https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/borrowck/README.md.

Oh, then the field approach is definitely correct - except for custom Drop impls, which require whole-value initialization "to be armed", what's the plan there?

Oh, then the field approach is definitely correct - except for custom Drop impls, which require whole-value initialization "to be armed", what's the plan there?

There is needs to be special treatment for types that implement drop, yes. The idea is that you can't have such a type in a "partially initialized" state, so you can't move out from its fields, nor can you write to a field if the type itself is not initialized.

eddyb · 2016-08-26T18:29:34Z

LGTM, great job!
I'm a bit sad about adding TyUnion and supporting trans::adt but I think it's easier to land this PR as-is and punt on those long-standing duplication issues.

r? @nikomatsakis for the borrowck bits & miscellaneous other details.

petrochenkov · 2016-08-26T18:39:42Z

I think it's easier to land this PR as-is and punt on those long-standing duplication issues.

That would be nice, this patch set bitrots relatively quickly.
Improvements/refactorings in trans can be made together with refactoring remains of the old trans (also, I don't have enough expertise in the area to do polishing).

nikomatsakis · 2016-08-26T19:09:23Z

src/librustc/middle/effect.rs

@@ -178,11 +177,28 @@ impl<'a, 'tcx, 'v> Visitor<'v> for EffectCheckVisitor<'a, 'tcx> {
                    self.require_unsafe(expr.span, "use of mutable static");
                }
            }
+            hir::ExprField(ref base_expr, field) => {
+                if let ty::TyUnion(..) = self.tcx.expr_ty_adjusted(base_expr).sty {


Nit: I feel like it'd be nice to match the sty (exhaustively) and have a bug! call for the unexpected cases. This makes me mildly nervous that some bug or addition might slip through.

nikomatsakis · 2016-08-26T21:48:29Z

src/librustc_trans/debuginfo/metadata.rs

+// Unions
+//=-----------------------------------------------------------------------------
+
+struct UnionMemberDescriptionFactory<'tcx> {


ping @michaelwoerister -- does this file look roughly right? :)

Looks pretty good to me!

nikomatsakis · 2016-08-26T22:13:24Z

OK, did a review. Here are my thoughts:

I was skeptical at first, but adding the Option<usize> to the MIR ADT does seem to work well. And I remember now that I was thinking of union as more of a repr attribute on struct, and that approach seems to fit with that interpretation (i.e., a struct where all fields are at offset 0). So I am happy with it.
The borrowck integration is not the way I imagined doing it. I had imagined that instead of adding a loan for every field whenever one is borrowed, we would instead change the equality metric so that if you accessed field.x and field.y is borrowed where x and y potentially overlap, we would error out.
- That said, this way is not bad.
- But I am unhappy about the dummy types and changing the def'n of Eq and so forth. I always think that a custom Eq is a sign of subtle logic and this seems to be no exception. Now you have to track which LoanPath instances have "real" types and which don't.
- But I do plan to be rewriting this to operate over MIR and maybe we can address it then.
- Have to think about this just a bit.
The test cases are looking pretty good. As has been my practice for big PRs like this, I am going to go through the RFC and try to make a list of important points in there. I'll concatenate that with a list of tests I wrote down while skimming through the code and post it to make sure we hit all the important points. Many of them you already covered in any case.
I agree with @eddyb that it'd be better to have TyAdt but also that this would be better done in a follow-up PR.

petrochenkov · 2016-08-26T22:26:59Z

@nikomatsakis

And I remember now that I was thinking of union as more of a repr attribute on struct

This is exactly how it turned out to be from implementation point of view. Unions tend to stay close to their syntactic surface representation and therefore treated in the same way as structs by most of compiler passes except for layout calculation and borrow/move checking.
I can imagine if union's syntax were modeled after enums, all the implementation would tend to enums instead.

nikomatsakis · 2016-08-26T22:32:50Z

OK here is my master list of tests. Feel free to check-off ones that you feel you already have (I have already done so in some cases, but I know you've got a lot of these covered already).

Here are some tests we could add, except that I think the impl will not work quite the way I would want (and I'm ok with that):

test that derive(Copy, Clone) works (or open a FIXME and leave a note on the tracking issue)
test deferred union initialization
- the rfc says let x: Union; x.f = 22; use(x); should work; however, this doesn't work right for structs afaik, so I think it's ok if it doesn't for now

nikomatsakis · 2016-08-26T22:33:31Z

One thing I thought of while doing this: we probably want to consider the borrowck error messages. i.e., I suspect they could give better advice (in general we try to point out when a restriction on path x is due to a borrow of some other path y). But we can leave this for later.

petrochenkov · 2016-08-26T22:33:35Z

The borrowck integration is not the way I imagined doing it.

What I wrote is just the simplest way to implement it :D
But it's also the simplest way to explain/document the behavior - "if one union's field is borrowed/moved/assigned then all its other fields are borrowed/moved/assigned as well".
(It also feels like the right model in general.)

But I am unhappy about the dummy types and changing the def'n of Eq and so forth.

That assert in PartialEq had to be removed anyway (see #36004), types can be slightly different even without unions.

nikomatsakis · 2016-08-26T22:34:05Z

Having thought about the borrowck -- I think I'm inclined to land it with this approach and consider patching it up and refactoring it later. This PR is too good to stall for long. :)

nikomatsakis · 2016-08-26T22:34:55Z

r=me once tests are set.

Make parsing of union items backward compatible Add some tests

Fix some typeck bugs blocking drop tests

Fix alignment for packed unions Add some missing privacy test Get rid of `unimplemented_unions` macro

Add some more tests

Fix union debuginfo test on lldb

petrochenkov · 2016-09-03T11:47:09Z

@bors r=nikomatsakis

bors · 2016-09-03T11:47:10Z

📌 Commit 436cfe5 has been approved by nikomatsakis

bors · 2016-09-03T14:48:07Z

⌛ Testing commit 436cfe5 with merge d748fa6...

@eddyb

Implement untagged unions (RFC 1444) cc #32836 Notes: - The RFC doesn't talk about `#[packed]` unions, this implementation supports them, packing changes union's alignment to 1 and removes trailing padding. - The RFC doesn't talk about dynamically sized unions, this implementation doesn't support them and rejects them during wf-checking (similarly, dynamically sized enums are not supported as well). - The lint for drop fields in unions can't work precisely before monomorphization, so it works pessimistically - non-`Copy` generic fields are reported, types not implementing `Drop` directly, but having non-trivial drop code are reported. ``` struct S(String); // Doesn't implement `Drop` union U<T> { a: S, // Reported b: T, // Reported } ``` - #35764 was indeed helpful and landed timely, I didn't have to implement internal drop flags for unions. - Unions are not permitted in constant patterns, because matching on union fields is unsafe, I didn't want unsafety checker to dig into all constants to uncover this possible unsafety. - The RFC doesn't talk about `#[derive]`, generally trait impls cannot be derived for unions, but some of them can. I implemented only `#[derive(Copy)]` so far. In theory shallow `#[derive(Clone)]` can be derived as well if all union fields are `Copy`, I left it for later though, it requires changing how `Clone` impls are generated. - Moving union fields is implemented as per #32836 (comment). - Testing strategy: union specific behavior is tested, sometimes very basically (e.g. debuginfo), behavior common for all ADTs (e.g. something like coherence checks) is not generally tested. r? @eddyb

bors · 2016-09-03T18:06:53Z

joshtriplett · 2016-09-03T18:27:51Z

Awesome work, @petrochenkov!

rust-highfive assigned eddyb Aug 26, 2016

petrochenkov mentioned this pull request Aug 26, 2016

Untagged unions (tracking issue for RFC 1444) #32836

Closed

5 tasks

eddyb reviewed Aug 26, 2016
View reviewed changes

rust-highfive assigned nikomatsakis and unassigned eddyb Aug 26, 2016

petrochenkov force-pushed the union branch from 0c339a6 to 1f5c074 Compare August 26, 2016 18:58

nikomatsakis reviewed Aug 26, 2016
View reviewed changes

petrochenkov mentioned this pull request Aug 26, 2016

rustc_borrowck: Don't hash types in loan paths #36004

Merged

nikomatsakis reviewed Aug 26, 2016
View reviewed changes

petrochenkov added 14 commits September 3, 2016 13:39

Fix rebase + address comments

c2ca153

Implement layout calculation and add more trans stubs

957971b

Check fields in union patters/expressions

f3b41c1

Make parsing of union items backward compatible Add some tests

Make accesses to union fields unsafe

e88d4ca

Implement drop translation and add lint for unions with drop fields

bea0b15

Fix some typeck bugs blocking drop tests

Fix buggy field access translation

0cb1938

Fix rebase

2dc2fc5

Translate union constants

d9b332b

Fix alignment for packed unions Add some missing privacy test Get rid of `unimplemented_unions` macro

Generate debuginfo for unions

079c390

Support deriving some traits for unions

59ccb7b

Support unions in borrow checker

5f975e9

Add some more tests

Fix rebase, fix some tests

e67c228

Address comments and add requested tests

93067ca

Fix type encoding/decoding for unions

436cfe5

Fix union debuginfo test on lldb

petrochenkov force-pushed the union branch from c424190 to 436cfe5 Compare September 3, 2016 11:35

bors merged commit 436cfe5 into rust-lang:master Sep 3, 2016

This was referenced Sep 3, 2016

Update Error format for E0516, E0517, E0518 #36128

Merged

Update the wording for E0063. This will truncate the fields to 3. #35691

Merged

Represent Option<bool> and Option<char> as 8bit and 32bit values #36237

Closed

Typecheck refactor for ! #35787

Merged

petrochenkov mentioned this pull request Sep 14, 2016

Improve shallow Clone deriving #36384

Merged

petrochenkov deleted the union branch September 21, 2016 20:00

Manishearth mentioned this pull request Jan 9, 2017

Remove destructor-related restrictions from unions #38934

Merged

petrochenkov mentioned this pull request Oct 24, 2019

Under what conditions can you implement Copy for a union? #65748

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement untagged unions (RFC 1444) #36016

Implement untagged unions (RFC 1444) #36016

petrochenkov commented Aug 26, 2016 •

edited

Loading

petrochenkov commented Aug 26, 2016 •

edited

Loading

eddyb Aug 26, 2016

petrochenkov Aug 26, 2016

eddyb Aug 26, 2016

petrochenkov Aug 26, 2016 •

edited

Loading

eddyb Aug 26, 2016

eddyb Aug 27, 2016

petrochenkov Aug 27, 2016 •

edited

Loading

eddyb Aug 27, 2016

nikomatsakis Aug 31, 2016 •

edited

Loading

eddyb commented Aug 26, 2016

petrochenkov commented Aug 26, 2016 •

edited

Loading

nikomatsakis Aug 26, 2016

nikomatsakis Aug 26, 2016

michaelwoerister Aug 26, 2016

nikomatsakis commented Aug 26, 2016

petrochenkov commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

petrochenkov commented Aug 26, 2016 •

edited

Loading

nikomatsakis commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

petrochenkov commented Sep 3, 2016

bors commented Sep 3, 2016

bors commented Sep 3, 2016

bors commented Sep 3, 2016

joshtriplett commented Sep 3, 2016

Implement untagged unions (RFC 1444) #36016

Implement untagged unions (RFC 1444) #36016

Conversation

petrochenkov commented Aug 26, 2016 • edited Loading

petrochenkov commented Aug 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov Aug 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov Aug 27, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis Aug 31, 2016 • edited Loading

Choose a reason for hiding this comment

eddyb commented Aug 26, 2016

petrochenkov commented Aug 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Aug 26, 2016

petrochenkov commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

petrochenkov commented Aug 26, 2016 • edited Loading

nikomatsakis commented Aug 26, 2016

nikomatsakis commented Aug 26, 2016

petrochenkov commented Sep 3, 2016

bors commented Sep 3, 2016

bors commented Sep 3, 2016

bors commented Sep 3, 2016

joshtriplett commented Sep 3, 2016

petrochenkov commented Aug 26, 2016 •

edited

Loading

petrochenkov commented Aug 26, 2016 •

edited

Loading

petrochenkov Aug 26, 2016 •

edited

Loading

petrochenkov Aug 27, 2016 •

edited

Loading

nikomatsakis Aug 31, 2016 •

edited

Loading

petrochenkov commented Aug 26, 2016 •

edited

Loading

petrochenkov commented Aug 26, 2016 •

edited

Loading