Refactor class to represent structure.

Refactor class to represent structure.

We had a TTypeLine to represent a structure field,
which simply encapsulated a TType and line number.
The line number was only used during parsing for error reporting.
There is no need to store a line number because it is already
available in the parser token.

TEST=WebGL conformance tests
R=kbr@chromium.org

Committed: https://code.google.com/p/angleproject/source/detail?r=2198

[kbr1, 2013-05-07 18:17:40]

https://codereview.appspot.com/9223045/diff/1/src/compiler/glslang.y
File src/compiler/glslang.y (right):

https://codereview.appspot.com/9223045/diff/1/src/compiler/glslang.y#newcode1729
src/compiler/glslang.y:1729: context->error($2.line, "duplicate field name in
structure:", "struct", field->getFieldName().c_str());
Does this still print the line on which the field was declared? I don't know how
to read this but it looks like it might be printing the line on which the struct
declaration begins.

[Alok Priyadarshi, 2013-05-07 19:44:22]

https://codereview.appspot.com/9223045/diff/1/src/compiler/glslang.y
File src/compiler/glslang.y (right):

https://codereview.appspot.com/9223045/diff/1/src/compiler/glslang.y#newcode1729
src/compiler/glslang.y:1729: context->error($2.line, "duplicate field name in
structure:", "struct", field->getFieldName().c_str());
It will print the correct line number in most cases. At this point
struct_declaration typically contains one member variable: "int foo;"

It may contain multiple member declarations of the same type: "int foo, bar,
baz;" The only case location will be wrong is if foo, bar, and baz are on
different lines, which is not typical.

I am working on another patch that refactors the way we track location. It will
fix the above case as well.

[kbr1, 2013-05-07 20:00:00]

OK. LGTM

[Alok Priyadarshi, 2013-05-07 20:23:26]

Committed patchset #1 manually as r2198 (presubmit successful).