Add DatatypeDef

[Aatch]

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]

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]

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

[eddyb]

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

[Aatch]

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

[eddyb]

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

[alexcrichton]

r? @nikomatsakis

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

[nikomatsakis]

Sorry for the delay. I somehow missed this PR.

[nikomatsakis]

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]

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]

Nit: Please don't drop this comment.

[nikomatsakis]

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.pubstructIvar<T:Copy>{data:Cell<Option<T>>}impl<T:Copy>Ivar<T>{pubfnget(&self) -> Option<T>{self.data.get()}pubfnfulfill(&self,value:T){assert!(self.data.get().is_none());self.data.set(value);}pubfnunwrap(&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]

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]

Pre-existing,but this comment formatting is terrible.

[nikomatsakis]

@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]

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

[pnkfelix]

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]

@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.

[nikomatsakis]

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

[bors]

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

[Ms2ger]

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

[nikomatsakis]

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]

@nikomatsakis sounds like an "OnceCell".

[pnkfelix]

@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]

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

[nikomatsakis]

@Aatch do you plan to rebase this?

[nikomatsakis]

@Aatch would you object if I rebased this?

[Aatch]

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

[nikomatsakis]

@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]

Closing in favor of @nikomatsakis's upcoming rebase