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>
Build bot data is no longer maintained and all logs are moving over to logdog.
Bug:
Change-Id: If3526bde1c950b936d9bf1e67bb53d19bffe7177
Reviewed-on: https://dart-review.googlesource.com/17222
Reviewed-by: William Hesse <whesse@google.com>
Additionally, combine all stream chunks into a single buffer, separated by new
line.
Bug:
Change-Id: I0c56aa1e99e76ee7ff578c84dc9e3ef534f5e63f
Reviewed-on: https://dart-review.googlesource.com/17221
Reviewed-by: William Hesse <whesse@google.com>
If you pass "-c" or "-r", but not both, choose a smart default for the
other instead of simply yelling at the user and telling them they
forgot something.
Change-Id: Ic47a20fa8f137a8f6488f16cf883839999e2225b
Reviewed-on: https://dart-review.googlesource.com/16905
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This allows dartdevk to compile tests that import packages like expect.
There are a few pieces to this:
- Add support to build_pkgs.dart to build the kernel summaries for each
test package (in addition to the analyzer summaries it already
builds).
- Plumb that through the dartdevc_test target in the GN build as well.
- While we're at it, use GN to build the ddc_sdk.dill file and have
test.dart load that one instead of the manually built one from calling
./tool/kernel_sdk.dart.
- Add command-line arguments to dartdevk for passing in the path to the
SDK summary and the other summaries to compile against.
- Fix a little typo in processed_options.dart that was preventing it
from resolving "package:" URIs.
- In test.dart, when compiling a test, link in the summaries for all of
the test packages.
At runtime, it still uses the JS for those packages generated from the
old analyzer-based front end since the kernel-based compiler isn't
complete enough to compile any of those packages yet.
With all of this, if I change a test to:
import "package:expect/expect.dart";
main() {
Expect.equals("a", "b");
}
Then it compiles but fails at runtime. The compiler is completing, but
the generated code has some bugs. I don't know enough to fix them
myself, but here's what I've found out:
- In _libraryToModule(), the Library we get from kernel has a null
fileUri, so this returns an empty string. That in turn means the
generated JS tries to use "$" as the module name.
Using this works around it temporarily:
if (moduleName.isEmpty) moduleName = library.name;
- In _emitTopLevelNameNoInterop(), it doesn't handle the case where the
NamedNode is a static method on a class. It just generates the library
and method name, skipping the class, so "Expect.equals(1, 2)" gets
compiled to "expect.equals(1, 2)" instead of
"expect.Expect.equals(1, 2)".
Change-Id: I6bd9d98bc9706965160d8fb7cf70b20eeebab3a8
Reviewed-on: https://dart-review.googlesource.com/16687
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Refactoring of failures tool with:
Reducing the time it takes for looking up status files by dividing entries in
the status file by wildcard and none-wildcard. Speciel attention is needed for
multitests.
Not report an error when Skip or SkipByDesign is added to the status files.
Report which status files expectations are taken from.
Bug:
Change-Id: I56a05a9bd79a5206ef5287a58d341165d98aaefc
Reviewed-on: https://dart-review.googlesource.com/16441
Reviewed-by: William Hesse <whesse@google.com>
This will make sure that the result.log file will always exist, even if no tests
are run. This also means that the delete result.log step for recipes can be
removed.
Bug:
Change-Id: Idf097acb990b047146a874715f992657deacf65a
Reviewed-on: https://dart-review.googlesource.com/16483
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
Updating the readme to better give a quick overview of how to use the results failures tool.
Bug:
Change-Id: Id6d4492e6a55e651886e9ccbbc88965248e1ac88
Reviewed-on: https://dart-review.googlesource.com/16740
Reviewed-by: William Hesse <whesse@google.com>
There was an error so these tests were run unless the --report flag was
present. This fixes that error. Testing for compile-time errors in non-browser
cases is sufficient.
Bug:
Change-Id: Ifeed1a3835297a9308a94de15cabfa119604c75a
R=mkroghj@google.com
Reviewed-on: https://dart-review.googlesource.com/14480
Reviewed-by: Morten Krogh-jespersen <mkroghj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Generate a manifest of just Dart's files, no longer rolling in the
main Fuchsia manifest. Use Fuchsia's new bootdata() template to
generate a BOOTFS image of just the Dart test files. A new Fuchsia
GN build argument will control rolling this into the final image.
IN-70
Change-Id: Idd2db5aab483f49d6f6f3e4065798ded130d606a
Reviewed-on: https://dart-review.googlesource.com/15987
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
- Clean up browser test failure output. Instead of barfing a giant blob
of JSON, show just the runtime error and its stack trace. In verbose
and on the buildbots, it still shows all the events, but even there
they are formatted nicely.
- Don't redundantly show the failure summary when most of the output is
already failure text.
- Color the failure summary end message.
Change-Id: I49724b204be55a297fc5e723b80b32e0e00748f0
Reviewed-on: https://dart-review.googlesource.com/15767
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This CL adds handling of previously introduced 'strong-aot'
implementation (target-specific) option into VM target.
After this change, it will be possible to enable strong-mode
whole-program optimizations in Flutter (in addition to standalone VM).
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I054b75ce4ba1b9bcf150e0b7f25fa7ca1bdd187e
Reviewed-on: https://dart-review.googlesource.com/15644
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
It's added as a new compiler, so pass "-c dartdevk" to use it.
It doesn't support any test packages yet, so tests that, say, import
package expect won't compile. I'll work on that next, but it will
require adding some stuff to the build scripts to build .dill files for
those packages.
This does get test.dart invoking the compiler, running the resulting
test, and correctly reporting the result:
- A test that doesn't throw an exception and stays within the bounds of
what is currently implemented in dartdevk passes.
- A test that compiles correctly but fails at runtime fails with a
RuntimeError.
- A test that contains a compile error fails with a non-zero exit code
and is reported as a CompileTimeError.
Change-Id: Icacbf1ff54dfe7aa4d245382d3b0aeb375cf105b
Reviewed-on: https://dart-review.googlesource.com/15420
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Of course, if you're not using the color formatter, it stays uncolored.
But this gets rid of some unnecessary empty lines and section headers
that have no content.
Change-Id: I5b83345c583b79468af84f4e67a12ee757a3105f
Reviewed-on: https://dart-review.googlesource.com/14720
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
- Fix fuzzy arrow errors.
- Default the Dart repo URI so it doesn't always need to be explicitly
set.
- Run dartfmt on everything.
- Move some members out of the garbage bin "TestUtils" class:
- Move the stuff around the Dart repo directory to a new Repository
class.
- Move absolute() into Path where it belongs.
- Move workingDirectory in Path since it is a Path.
- Delete the random number stuff since it was apparently unused.
Change-Id: I3dab3a4f1713b7a749e64b6776149d05a0ce1b69
Reviewed-on: https://dart-review.googlesource.com/14502
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Erik Ernst