Add a "Label" Node around an Identifier that is being used as a label.

Add a "Label" Node around an Identifier that is being used as a label.

This is in preparation for rewriting switch to match the "new" switch grammar.
I need to make a block information structure for switch statements, and I don't
want to do that on an obsolete structure.

Committed: https://code.google.com/p/dart/source/detail?r=7485

[Lasse Reichstein Nielsen, 2012-05-10 11:27:18]

PTAnotherL.

[ahe, 2012-05-10 11:52:30]

Much better, thank you. LGTM!

Cheers,
Peter

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/elements/elements.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/elements/elements.dart:988: final Label label;
Could you add a comment explaining why you need the AST node here. Normally, we
don't like requiring AST nodes for elements, but in this case it makes sense.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/ssa/builder.dart:2822: unreachable();
I really don't like using this method. You have a node, so use it to report a
nice error message.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/tree/nodes.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/tree/nodes.dart:1460: String get name() =>
identifier.source.slowToString();
I don't like that you hide that you call slowToString, especially in a getter.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/typechecker.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/typechecker.dart:707: fail(node);
No need to fail here. Just do nothing.

[Lasse Reichstein Nielsen, 2012-05-10 12:14:20]

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/elements/elements.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/elements/elements.dart:988: final Label label;
On 2012/05/10 11:52:30, ahe wrote:
> Could you add a comment explaining why you need the AST node here. Normally,
we
> don't like requiring AST nodes for elements, but in this case it makes sense.

Done.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/ssa/builder.dart:2822: unreachable();
True, also the comment is no longer valid.
Using internalError like in some other places.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/tree/nodes.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/tree/nodes.dart:1460: String get name() =>
identifier.source.slowToString();
Let's rename it to slowToString too.

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/typechecker.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/typechecker.dart:707: fail(node);
Done.
Why do we need to fail in the cases below?

[ahe, 2012-05-10 12:40:25]

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
File lib/compiler/implementation/typechecker.dart (right):

https://chromiumcodereview.appspot.com/10392024/diff/3001/lib/compiler/implem...
lib/compiler/implementation/typechecker.dart:707: fail(node);
On 2012/05/10 12:14:20, Lasse Reichstein Nielsen wrote:
> Done.
> Why do we need to fail in the cases below?

Ask Karl. The cases below are not implemented so the type checker gives up (that
is what "fail" means in this context).