Add DatatypeDef #22564

Aatch · 2015-02-20T06:39:18Z

Add a DatatypeDef type that contains information for both structs and enums. Most places already treated structs like single-variant enums or vice-versa, so this actually simplifies a lot of code.

There is a small but significant performance increase in typechecking and translation (pre-optimisations) of about 5% in both phases. All the other phases seemed to have some performance improvements too, but the differences were too small to be meaningful.

This change is also a step towards overall simplification of the type system code. Given how many places are now treating enums and structs completely identically, a move towards a unified ty_data type is somewhat feasible.

rust-highfive · 2015-02-20T06:39:33Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

eddyb · 2015-02-20T07:59:30Z

I would prefer a name like DataType, but that's... bikeshedding.
cc @nikomatsakis @nick29581

eddyb · 2015-02-20T08:00:35Z

src/librustc/lint/builtin.rs

+        let ty = match ty::expr_ty_opt(cx.tcx, e) {
+            Some(ty) => ty,
+            None => cx.tcx.sess.span_bug(e.span, "No type for expression"),
+        };


Doesn't/can't ty::expr_ty handle this?

Ah right, that reminds me, I was going to fold the span_bug stuff into ty::expr_ty. Makes debugging easier.

eddyb · 2015-02-20T08:29:44Z

LGTM modulo some nits, but I'd be happy with a second pair of eyes.

alexcrichton · 2015-02-20T16:39:52Z

r? @nikomatsakis

(I'm probably not the right reviewer for this)

nikomatsakis · 2015-02-25T10:27:16Z

Sorry for the delay. I somehow missed this PR.

nikomatsakis · 2015-02-25T11:02:53Z

src/librustc/middle/ty.rs

+
+    pub fn ty(&self) -> Ty<'tcx> {
+        self.ty.get()
+    }


The current setup, iiuc, initially stores a ty_err and then updates it to the actual type. This seems like it will hide bugs where we read the type of a field before it is fully initialized. I would prefer to use Cell<Option<Ty<'tcx>>> and initially set it to None. Then ty can call self.ty.get().unwrap(), which will give the same (stronger) guarantees we get today. Similarly set_ty can check that the type is set exactly once. (There is no space inefficiency because Ty<'tcx> is a non-nullable-pointer.)

nikomatsakis · 2015-02-25T11:07:33Z

ok, I have to run for the moment. I'm a big fan of this general approach. I've been wanting to see the struct/enum code made nicer (and unified!) for a long time, and I think moving away from storing all the information in distinct side-tables is generally a good idea. I've only had time though to read over the high-level details of what is here, so I'll want some more time to soak in finer points.

nikomatsakis · 2015-02-25T20:13:54Z

src/librustc_privacy/lib.rs

-                    ty::ty_struct(ctor_id, _) => {
-                        // RFC 736: ensure all unmentioned fields are visible.
-                        // Rather than computing the set of unmentioned fields
-                        // (i.e. `all_fields - fields`), just check them all.


Nit: Please don't drop this comment.

nikomatsakis · 2015-02-25T20:20:59Z

I think I'd like to see the Cell<Option<Ty<'tcx>>> replaced with an Ivar<Ty<'tcx>>, where Ivar would be a type in librustc/middle/util/ivar.rs:

/// A "write once" cell.
pub struct Ivar<T:Copy> {
    data: Cell<Option<T>>
}

impl<T:Copy> Ivar<T> {
    pub fn get(&self) -> Option<T> {
        self.data.get()
    }

    pub fn fulfill(&self, value: T) {
        assert!(self.data.get().is_none());
        self.data.set(value);
    }

    pub fn unwrap(&self) -> T {
        self.get().unwrap()
    }
}

This has the advantage that (a) privacy ensures that we will only write to the cell once and (b) it can, in the future, be made Sync (we'd have to use atomic writes).

Aatch · 2015-02-26T06:18:52Z

I've squashed all the previous commits since rebasing was getting difficult due to functions being removed/replaced and me having to manually re-remove them post-rebase.

I have also added the Ivar type and used it for DatatypeDef

nikomatsakis · 2015-02-26T14:50:28Z

src/librustc/metadata/encoder.rs

-        encode_struct_fields(rbml_w, &fields[..], def_id);
+          /* Encode def_ids for each field and method
+          for methods, write all the stuff get_trait_method
+          needs to know*/


Pre-existing,but this comment formatting is terrible.

nikomatsakis · 2015-02-26T14:57:12Z

@Aatch I commented on a few points that were made before but not corrected in your latest rebase. Overall I'm pretty happy with this.

One thing I was wondering -- perhaps it would make sense to merge ty_struct and ty_enum into ty_data or something like that. Just something to think about, for now.

nikomatsakis · 2015-02-26T15:05:59Z

Modulo those nits though I'm ready to r+.

pnkfelix · 2015-02-26T15:11:57Z

src/librustc/util/ivar.rs

+    data: Cell<Option<T>>
+}
+
+impl<T:Copy> Ivar<T> {


I personally know what an "I-var" is, but it might be nice to either have some comments here just saying what the big picture is about them, or a pointer to http://en.wikipedia.org/wiki/Futures_and_promises or something.

(This comment should have been on the struct definition itself)

Aatch · 2015-02-27T00:27:29Z

@nikomatsakis yeah, I looked at merging them into a ty_data, but it's a non-trivial change on top of this already fairly extensive change. Definitely something to do in the near future though.

Add a DatatypeDef type that contains information for both structs and enums. Most places already treated structs like single-variant enums or vice-versa, so this actually simplifies a lot of code.

Adds an Ivar for write-once variables, and makes DatatypeDef use it. Removes some now-unused arguments.

Re-add removed comment in librustc_privacy Remove `vis` field from `VariantDef` Fixup weirdly-formatted comments in metadata::encoder

Documents `Ivar` and adds some common trait implementations for it

nikomatsakis · 2015-02-27T14:43:18Z

r+ from me, but of course there are tidy errors it looks like

bors · 2015-02-28T08:31:03Z

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

Ms2ger · 2015-02-28T09:52:01Z

There's a lot of &x[] slicing syntax, that I believe to be deprecated.

nikomatsakis · 2015-02-28T10:34:52Z

I was thinking about Ivar and I remembered that as I originally envisioned it, Ivar wouldn't require T:Copy but, rather, would take advantage of the fact that because it is only set once, it can return an &T to the contents even without using a RefCell (this would require unsafe code, of course). This doesn't have to go in the PR, I'm just noting it for future reference. ;)

eddyb · 2015-02-28T10:43:46Z

@nikomatsakis sounds like an "OnceCell".

pnkfelix · 2015-03-01T20:21:40Z

@eddyb I am not 100% sure I would apply the Cell terminology here, since part of the point is that these things do not start with an initial value, while all of the current kinds of cells do start with an initial value, right?

eddyb · 2015-03-01T20:53:22Z

@pnkfelix fair enough, I was just trying to force it into std::cell, but it probably fits better somewhere in std::sync.

nikomatsakis · 2015-03-17T13:38:09Z

@Aatch do you plan to rebase this?

nikomatsakis · 2015-04-08T14:04:29Z

@Aatch would you object if I rebased this?

Aatch · 2015-04-17T01:18:00Z

@nikomatsakis go for it. Sorry, I've been really busy with work + life recently, not much time for compiler-hacking.

nikomatsakis · 2015-04-17T14:11:10Z

@Aatch I started it. Lots of conflicts (of course). I might just try to cherry-pick and re-implement instead...gotta finish a few other things first.

alexcrichton · 2015-05-01T17:27:41Z

Closing in favor of @nikomatsakis's upcoming rebase

rust-highfive assigned alexcrichton Feb 20, 2015

eddyb reviewed Feb 20, 2015
View reviewed changes

rust-highfive assigned nikomatsakis and unassigned alexcrichton Feb 20, 2015

nikomatsakis reviewed Feb 25, 2015
View reviewed changes

huonw mentioned this pull request Feb 25, 2015

Handle stability of struct fields #22803

Merged

Aatch force-pushed the ty-def branch from 1e9e7bc to 7df4133 Compare February 26, 2015 06:16

nikomatsakis reviewed Feb 26, 2015
View reviewed changes

pnkfelix reviewed Feb 26, 2015
View reviewed changes

Aatch added 5 commits February 27, 2015 13:28

Add DatatypeDef

7a6d342

Add a DatatypeDef type that contains information for both structs and enums. Most places already treated structs like single-variant enums or vice-versa, so this actually simplifies a lot of code.

Add an Ivar for write-once variables

c12c238

Adds an Ivar for write-once variables, and makes DatatypeDef use it. Removes some now-unused arguments.

Revert subproject commit

eaba2ae

Address Comments

b2ce429

Re-add removed comment in librustc_privacy Remove `vis` field from `VariantDef` Fixup weirdly-formatted comments in metadata::encoder

Document and extend Ivar

777796b

Documents `Ivar` and adds some common trait implementations for it

Aatch force-pushed the ty-def branch from 7df4133 to 777796b Compare February 27, 2015 02:04

alexcrichton closed this May 1, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add DatatypeDef #22564

Add DatatypeDef #22564

Aatch commented Feb 20, 2015

rust-highfive commented Feb 20, 2015

eddyb commented Feb 20, 2015

eddyb Feb 20, 2015

Aatch Feb 20, 2015

eddyb commented Feb 20, 2015

alexcrichton commented Feb 20, 2015

nikomatsakis commented Feb 25, 2015

nikomatsakis Feb 25, 2015

nikomatsakis commented Feb 25, 2015

nikomatsakis Feb 25, 2015

nikomatsakis commented Feb 25, 2015

Aatch commented Feb 26, 2015

nikomatsakis Feb 26, 2015

nikomatsakis commented Feb 26, 2015

nikomatsakis commented Feb 26, 2015

pnkfelix Feb 26, 2015

Aatch commented Feb 27, 2015

nikomatsakis commented Feb 27, 2015

bors commented Feb 28, 2015

Ms2ger commented Feb 28, 2015

nikomatsakis commented Feb 28, 2015

eddyb commented Feb 28, 2015

pnkfelix commented Mar 1, 2015

eddyb commented Mar 1, 2015

nikomatsakis commented Mar 17, 2015

nikomatsakis commented Apr 8, 2015

Aatch commented Apr 17, 2015

nikomatsakis commented Apr 17, 2015

alexcrichton commented May 1, 2015

Add DatatypeDef #22564

Add DatatypeDef #22564

Conversation

Aatch commented Feb 20, 2015

rust-highfive commented Feb 20, 2015

eddyb commented Feb 20, 2015

eddyb Feb 20, 2015

Choose a reason for hiding this comment

Aatch Feb 20, 2015

Choose a reason for hiding this comment

eddyb commented Feb 20, 2015

alexcrichton commented Feb 20, 2015

nikomatsakis commented Feb 25, 2015

nikomatsakis Feb 25, 2015

Choose a reason for hiding this comment

nikomatsakis commented Feb 25, 2015

nikomatsakis Feb 25, 2015

Choose a reason for hiding this comment

nikomatsakis commented Feb 25, 2015

Aatch commented Feb 26, 2015

nikomatsakis Feb 26, 2015

Choose a reason for hiding this comment

nikomatsakis commented Feb 26, 2015

nikomatsakis commented Feb 26, 2015

pnkfelix Feb 26, 2015

Choose a reason for hiding this comment

Aatch commented Feb 27, 2015

nikomatsakis commented Feb 27, 2015

bors commented Feb 28, 2015

Ms2ger commented Feb 28, 2015

nikomatsakis commented Feb 28, 2015

eddyb commented Feb 28, 2015

pnkfelix commented Mar 1, 2015

eddyb commented Mar 1, 2015

nikomatsakis commented Mar 17, 2015

nikomatsakis commented Apr 8, 2015

Aatch commented Apr 17, 2015

nikomatsakis commented Apr 17, 2015

alexcrichton commented May 1, 2015