Static members are not visible in subclasses

Static members are not visible in subclasses

Fix for issue 1598.

Lexical scope comes before inherited names. Also, Static members
are not inherited and are not visible in subclasses.
Code in the subclass (or any other code for that matter) has to
qualify the names of these members with the class name.

We had a few tests that were wrong and only passed in the VM because
this was not implemented correctly.

Also had to fix code in frog and dartdoc.

I hope I ran enough tests. I built an all.deps tree using tools/build.py from the root directory, which brought up the frog and dartdoc issues.

Tested:
tools/test.py --compiler=dart2js --runtime=drt
tools/test.py -c none -r drt
tools/test.py -c frog -r drt
tools/test.py -r vm

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

[Bob Nystrom, 2012-04-18 00:03:51]

Dartdoc change LGTM.

[siva, 2012-04-18 00:56:23]

LGTM

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart
File frog/tokenizer.dart (right):

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart#newcode1
frog/tokenizer.dart:1: // Copyright (c) 2011, the Dart project authors.  Please
see the AUTHORS file
2012 (here and a few other files and tests cases).

http://codereview.chromium.org/10115005/diff/9/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

http://codereview.chromium.org/10115005/diff/9/runtime/vm/parser.cc#newcode6982
runtime/vm/parser.cc:6982: // Nothing found in scope of current class.
As discussed offline we need to figure if this will cause a performance
regression in the benchmarks and startup times. If it does impact performance
then it might make sense to add a ResolveInSuperClasses which only tries to
resolve instance fields/functions in the superclass.

[sra1, 2012-04-18 02:56:15]

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.g.dart
File frog/tokenizer.g.dart (right):

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.g.dart#newcode7
frog/tokenizer.g.dart:7: /** A generated file that extends the hand coded
methods in TokenizerBase. */
This is a generated file.
You need to change scripts/tokenizer_gen.py
and manually re-run it.

[sra1, 2012-04-18 02:59:51]

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart
File frog/tokenizer.dart (right):

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart#newcode4
frog/tokenizer.dart:4: // Generated by scripts/tokenizer_gen.py.
Please fix this file by changing the generator and re-running it.

run ./scripts/tokenizer_gen.py from the frog directory

[ahe, 2012-04-18 10:35:20]

Tests LGTM.

As for frog, I don't mind if you update the generated file manually. I think if
you check-in generated sources (instead of updating the build process) this
happens.

[hausner, 2012-04-18 16:49:26]

Thanks for the reviews

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart
File frog/tokenizer.dart (right):

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart#newcode1
frog/tokenizer.dart:1: // Copyright (c) 2011, the Dart project authors.  Please
see the AUTHORS file
On 2012/04/18 00:56:23, asiva wrote:
> 2012 (here and a few other files and tests cases).

Done.

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.dart#newcode4
frog/tokenizer.dart:4: // Generated by scripts/tokenizer_gen.py.
On 2012/04/18 02:59:52, sra1 wrote:
> Please fix this file by changing the generator and re-running it.
> 
> run ./scripts/tokenizer_gen.py from the frog directory

Since the generated file is checked in, I'll check in my hand-made changes and
file a bug to adapt the python file. I took a look at the generator and it's not
straight-forward to fix, at least for me.

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.g.dart
File frog/tokenizer.g.dart (right):

http://codereview.chromium.org/10115005/diff/9/frog/tokenizer.g.dart#newcode7
frog/tokenizer.g.dart:7: /** A generated file that extends the hand coded
methods in TokenizerBase. */
On 2012/04/18 02:56:15, sra1 wrote:
> This is a generated file.
> You need to change scripts/tokenizer_gen.py
> and manually re-run it.
See comment response in tokenizer.dart

http://codereview.chromium.org/10115005/diff/9/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

http://codereview.chromium.org/10115005/diff/9/runtime/vm/parser.cc#newcode6982
runtime/vm/parser.cc:6982: // Nothing found in scope of current class.
Yes. If necessary, I will do that as a separate change.

On 2012/04/18 00:56:23, asiva wrote:
> As discussed offline we need to figure if this will cause a performance
> regression in the benchmarks and startup times. If it does impact performance
> then it might make sense to add a ResolveInSuperClasses which only tries to
> resolve instance fields/functions in the superclass.