Remove the template magic from types.(h|cc), remove types-inl.h.

Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org

Committed: https://crrev.com/ef35f11c430264f80885bc6825bc4fe1f0ee5e8d
Cr-Commit-Position: refs/heads/master@{#33656}

[Jarin, 2016-02-01 11:39:42]

Description was changed from

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

BUG=
==========

to

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

BUG=
==========

[Jarin, 2016-02-01 11:39:42]

jarin@chromium.org changed reviewers:
+ bmeurer@chromium.org

[Jarin, 2016-02-01 11:48:48]

Could you take a look, please?

[Benedikt Meurer, 2016-02-01 18:24:26]

Wow... C++... but good to see this template hell going away. I'd actually prefer
to split off some unrelated changes, but I think it's not worth the pain, esp.
since rebasing this CL will already cause a lot of pain. So this is LGTM from my
side.

[rossberg, 2016-02-01 18:35:02]

> The CL also changes the type hierarchy - the specific type kinds are
> not inner classes of the Type class and they do not inherit from Type.
> This is partly because it seems impossible to make this work without
> templates. Instead, a new TypeBase class is introduced and all the
> structural (i.e., non-bitset) types inherit from it.

Are you sure this is needed? Can you elaborate what the problem is?
I find it rather surprising that something works with templates but not
without them, usually it's the other way round. (I also seem to remember
that this hierarchy was there before I even templatised the thing, but I
might misremember.)

[Jarin, 2016-02-02 05:39:35]

On 2016/02/01 18:35:02, rossberg wrote:
> > The CL also changes the type hierarchy - the specific type kinds are
> > not inner classes of the Type class and they do not inherit from Type.
> > This is partly because it seems impossible to make this work without
> > templates. Instead, a new TypeBase class is introduced and all the
> > structural (i.e., non-bitset) types inherit from it.
> 
> Are you sure this is needed? Can you elaborate what the problem is?
> I find it rather surprising that something works with templates but not
> without them, usually it's the other way round. (I also seem to remember
> that this hierarchy was there before I even templatised the thing, but I
> might misremember.)

Here is the problem:

Various inline methods in Type, such as Type::Range, use methods of 
the derived types, such as RangeType::New. In the templated version, it 
seems to be ok because the RangeType has already been defined by the time
the template is instantiated. Without templates, the method is not 
defined yet. Maybe it would help if I moved the inline method definitions 
out of the Type class definition. I will try that.

[Jarin, 2016-02-02 05:39:38]

On 2016/02/01 18:35:02, rossberg wrote:
> > The CL also changes the type hierarchy - the specific type kinds are
> > not inner classes of the Type class and they do not inherit from Type.
> > This is partly because it seems impossible to make this work without
> > templates. Instead, a new TypeBase class is introduced and all the
> > structural (i.e., non-bitset) types inherit from it.
> 
> Are you sure this is needed? Can you elaborate what the problem is?
> I find it rather surprising that something works with templates but not
> without them, usually it's the other way round. (I also seem to remember
> that this hierarchy was there before I even templatised the thing, but I
> might misremember.)

Here is the problem:

Various inline methods in Type, such as Type::Range, use methods of 
the derived types, such as RangeType::New. In the templated version, it 
seems to be ok because the RangeType has already been defined by the time
the template is instantiated. Without templates, the method is not 
defined yet. Maybe it would help if I moved the inline method definitions 
out of the Type class definition. I will try that.

[Jarin, 2016-02-02 06:17:30]

On 2016/02/02 05:39:38, Jarin wrote:
> On 2016/02/01 18:35:02, rossberg wrote:
> > > The CL also changes the type hierarchy - the specific type kinds are
> > > not inner classes of the Type class and they do not inherit from Type.
> > > This is partly because it seems impossible to make this work without
> > > templates. Instead, a new TypeBase class is introduced and all the
> > > structural (i.e., non-bitset) types inherit from it.
> > 
> > Are you sure this is needed? Can you elaborate what the problem is?
> > I find it rather surprising that something works with templates but not
> > without them, usually it's the other way round. (I also seem to remember
> > that this hierarchy was there before I even templatised the thing, but I
> > might misremember.)
> 
> Here is the problem:
> 
> Various inline methods in Type, such as Type::Range, use methods of 
> the derived types, such as RangeType::New. In the templated version, it 
> seems to be ok because the RangeType has already been defined by the time
> the template is instantiated. Without templates, the method is not 
> defined yet. Maybe it would help if I moved the inline method definitions 
> out of the Type class definition. I will try that.

Hmm, it is a bit harder than I thought. The trouble is that the inner classes
cannot be defined inline, so the outer class cannot really refer to anything
inside the inner classes. 

For example, the code below cannot be written without templates, but works 
just fine with the templatization (I hope there are not too many typos there).

class Type {
 public:
  class StructuralType;
  bool IsKind(StruturalType::Tag tag); // Using incomplete type.
};


class StructuralType : public Type {
 public:
  enum Tag { ... }
};

I suppose I could move methods around, but I would prefer not to do that
because it leads to hard-to-change code. What do you think?

[Jarin, 2016-02-02 06:45:53]

The CQ bit was checked by jarin@chromium.org

[Jarin, 2016-02-02 06:45:54]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1655833002/#ps100001
(title: "Rebase")

[commit-bot: I haz the power, 2016-02-02 06:46:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1655833002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1655833002/100001

[commit-bot: I haz the power, 2016-02-02 06:51:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-02 06:51:29]

Try jobs failed on following builders:
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/10398)

[Jarin, 2016-02-02 06:53:35]

Description was changed from

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

BUG=
==========

to

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org
==========

[Jarin, 2016-02-02 06:53:47]

The CQ bit was checked by jarin@chromium.org

[Jarin, 2016-02-02 06:53:47]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1655833002/#ps120001
(title: "Undo whitespace change")

[commit-bot: I haz the power, 2016-02-02 06:53:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1655833002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1655833002/120001

[commit-bot: I haz the power, 2016-02-02 07:25:41]

Description was changed from

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org
==========

to

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org
==========

[commit-bot: I haz the power, 2016-02-02 07:25:41]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-02-02 07:26:18]

Description was changed from

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org
==========

to

==========
Remove the template magic from types.(h|cc), remove types-inl.h.

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org

Committed: https://crrev.com/ef35f11c430264f80885bc6825bc4fe1f0ee5e8d
Cr-Commit-Position: refs/heads/master@{#33656}
==========

[commit-bot: I haz the power, 2016-02-02 07:26:19]

Patchset 7 (id:??) landed as
https://crrev.com/ef35f11c430264f80885bc6825bc4fe1f0ee5e8d
Cr-Commit-Position: refs/heads/master@{#33656}

[bradnelson, 2016-02-02 22:01:19]

bradnelson@chromium.org changed reviewers:
+ bradnelson@chromium.org

[bradnelson, 2016-02-02 22:01:20]

Wow, missed this until I hit a merge.
But glad to see the split go away!
lgtm