This CL modifies the Dart source used from test.py such that it takes
`syntax error` into account as an expected outcome in test files (so
that we can have `//# 01: syntax error` with a similar meaning as
`//# 01: compile-time error`).
For all tools except the spec_parser, `syntax error` is the same
outcome as `compile-time error`; that is, nobody else will see the
difference.
For the spec_parser, `syntax error` is the outcome where parsing has
failed; `compile-time error` is taken to mean some other compile-time
error, i.e., the spec_parser is expected to _succeed_ when the
expected outcome is `compile-time error`.
Test files in language and language_2 have been adjusted to use the
outcome `syntax error` where appropriate.
The status files in language and language_2 for the spec_parser have
been adjusted such that they fit all the new `syntax error` outcomes
in test files.
Other status files have been adjusted in a few cases where tests were
corrected (because a compile-time error which was clearly not intended
to be a syntax error turned out to be caused by a typo, which means
that the actual compile-time error has never been tested).
The spec grammar Dart.g was adjusted in a few cases, when some bugs
were discovered. In particular, the treatment of Function has been
changed: It is now known by the parser that Function does not take
any type arguments. This makes no difference for developers, because
they cannot declare a type named Function anyway, but it means that
a number of tricky parsing issues were resolved.
Dart.g was also adjusted to allow `qualified` to contain three
identifiers, which is an old bug (preventing things like metadata on
the form `@p.C.myConst`).
Change-Id: Ie420887d45c882ef97c84143365219f8aa0d2933
Reviewed-on: https://dart-review.googlesource.com/18262
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
generic_instanceof ... getter_closure_execution_order_test.
The main interesting one is generic_methods_type_expression_test. It
was testing old Dart 1.0-specific behavior and needed a lot of changes.
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/3001803002 .
Update all tests
Support //# multitests for better dartfmt compatibility and fewer multitest false positives
All files under tests were manually updated with
find . -iregex '.*\.dart$' -print0 | xargs -0 perl -pi -e 's/(\S\s+)\/\/\/ /$1\/\/# /'
For now both old and new styles are allowed to accommodate CO19 tests.
R=efortuna@google.com
BUG=
Review-Url: https://codereview.chromium.org/2765693002 .
Review-Url: https://codereview.chromium.org/2765893003 .
Support //# multitests for better dartfmt compatibility and fewer multitest false positives
All files under tests were manually updated with
find . -iregex '.*\.dart$' -print0 | xargs -0 perl -pi -e 's/(\S\s+)\/\/\/ /$1\/\/# /'
For now both old and new styles are allowed to accommodate CO19 tests.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2765693002 .
delayed class parsing in Dart VM.
- Some of the tests under tests/language expect compile-time errors but
these tests do not use the class which has errors. When the VM will
implement delayed parsing of classes (classes are parsed only if they
are used) these tests will fail as the Dart VM will not report these as
compile-time errors. The option VMOptions=--compile_all has been added
to these tests to ensure that all classes are compiled and the error
is reported.
- One co19 test has a similar issue and a bug has been filed against it
(co19 issue 415). the co19-runtime.status file has been updated to
skip this test until issue 415 is resolved.
R=iposva@google.com
Review URL: https://codereview.chromium.org//15496005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@23113 260f80e4-7a28-3924-810f-c04153c831b5
This is the second try to my previous attempt to implement the
new abstract class handling. Instead of a compile-time error,
the VM now throws an AbstractClassInstantiationError at runtime
if an abstract class is instantiated. Added the new error class
to the core library.
For now I'm still using the rule that a class is abstract if it is explicitly
marked as abstract, or if it defines a new abstract method.
Review URL: https://chromiumcodereview.appspot.com//10916039
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@11708 260f80e4-7a28-3924-810f-c04153c831b5
Erik Ernst