Eliminate bitfield enum members.

Eliminate bitfield enum members.

BUG=448

[Zhenyao Mo, 2013-08-29 00:33:57]

LGTM

Tried on my linux, which failed with the reverted commit and worked OK with this
CL.

https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h
File src/compiler/Types.h (right):

https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h#newcode241
src/compiler/Types.h:241: bool matrix;
nit: remove the tab character here.

[Alok Priyadarshi, 2013-08-29 05:19:53]

https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h
File src/compiler/Types.h (right):

https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h#newcode240
src/compiler/Types.h:240: char size;
can we use a portable version of uint8_t to make the intent clear.

[nicolas, 2013-09-09 15:16:56]

On 2013/08/29 05:19:53, Alok Priyadarshi wrote:
> https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h
> File src/compiler/Types.h (right):
> 
> https://codereview.appspot.com/13239046/diff/1/src/compiler/Types.h#newcode240
> src/compiler/Types.h:240: char size;
> can we use a portable version of uint8_t to make the intent clear.

Unfortunately when I include stdint.h it causes a number of macro redefinitions
because Flex defines them too. I could define/typedef just uint8_t in this file
but that kind of defeats the purpose I think. However, simply using "unsigned
char" instead of "char" may already help clarify that this isn't intended to be
a character?

[Alok Priyadarshi, 2013-09-09 16:46:37]

unsigned char would be fine too.

[nicolas, 2013-09-25 18:53:22]

On 2013/09/09 16:46:37, Alok Priyadarshi wrote:
> unsigned char would be fine too.

PTAL

[Alok Priyadarshi, 2013-09-25 21:51:39]

lgtm

https://codereview.appspot.com/13239046/diff/9001/src/compiler/Types.h
File src/compiler/Types.h (right):

https://codereview.appspot.com/13239046/diff/9001/src/compiler/Types.h#newcod...
src/compiler/Types.h:118: int getNominalSize() const { return size; }
is there any problem with returning "unsigned char" from here?

[Geoff Lang, 2013-10-01 14:26:31]

LGTM

[nicolas, 2013-10-02 19:57:07]

On 2013/09/25 21:51:39, Alok Priyadarshi wrote:
> lgtm
> 
> https://codereview.appspot.com/13239046/diff/9001/src/compiler/Types.h
> File src/compiler/Types.h (right):
> 
>
https://codereview.appspot.com/13239046/diff/9001/src/compiler/Types.h#newcod...
> src/compiler/Types.h:118: int getNominalSize() const { return size; }
> is there any problem with returning "unsigned char" from here?

No specific problem but any use of these values in other calculations quickly
leads to implicitly expanding them to 32-bit. When returning an unsigned char it
really returns a 32-bit register already so we might as well do this expansion
very early on. It also avoids a change in the interface of the class in case the
wrong header is used.