And so there is no need to maintain status files for this platform.
R=whesse@google.com
Change-Id: Ie70e4b7308cfd9b1b179b2d1eeeb8f36dd1a62dc
Reviewed-on: https://dart-review.googlesource.com/34824
Commit-Queue: Erik Corry <erikcorry@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This will be helpful when computing overlapping sections and
other manipulations of status files.
Bug:
Change-Id: I8896e9684cc65bdd971451ab9b6cb39732984f68
Reviewed-on: https://dart-review.googlesource.com/23260
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
All status files from the tests/ and runtime/tests directories has been copied
to a local directory, to make sure, that the unit test does not break when junk
is added to status files.
The linter has been updated with a check for duplicate entries in status files,
which is why the normalizer unit tests failed in the first place.
Bug:
Change-Id: Ifebd2bfd9011373bfe9a613de5c365ff99535ca4
Reviewed-on: https://dart-review.googlesource.com/25380
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
The test in this CL will test if the transformation of a status file produce an
equivalent status file. It does this by checking the number of entries and
making sure to find ONE entry in the produced status file.
As an invariant it needs that no duplicate entries exists in sections.
Bug:
Change-Id: I6aec3b20ef1bca89d6a7cf72d85487a95c3d1f0a
Reviewed-on: https://dart-review.googlesource.com/21341
Reviewed-by: Alexander Thomas <athom@google.com>
This both works as a tester for correct canonicalization of status files and can
be used later to check if changes to status files follow the guide lines.
It checks that:
- Comments only exists before a section or after a test path entry.
- That there are no disjunctions in headers.
- That variables and clauses are correctly ordered in section headers.
- That paths are alphabetically ordered in sections.
- That sections are lexicographically ordered with respect to negation.
Bug:
Change-Id: I0f5e2cc16f20bb48ee53a9a55a22aaab710e32ff
Reviewed-on: https://dart-review.googlesource.com/17786
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Morten Krogh-jespersen <mkroghj@google.com>
They aren't used by anything yet (except the unit test), but this
should help write tools to normalize and lint status files.
Change-Id: Iabd1342b7eda6137a059514834b6c72b089042d6
Reviewed-on: https://dart-review.googlesource.com/18428
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
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>
It will normalize white space and comments. It will further identify comments as
belonging to sections or being commen entries.
Bug:
Change-Id: I140780aa0ad9c675197907198b3ec6ab4d5dc742
Reviewed-on: https://dart-review.googlesource.com/17784
Reviewed-by: William Hesse <whesse@google.com>
For the migration script, I need a (less hacky) way of programmatically
modifying a status file. As a step along that path, I need the ability
to write a status file to disc given a StatusFile object.
With that, it was a small step to write a little "formatter" that turns
a status file into its canonical representation.
It removes unneeded parentheses in expressions, normalizes expectation
case, and normalizes whitespace. Seems useful.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2988383002 .
This looks at all the files in the batch being migrated. It goes through
the status files in the 1.0 and strong directories. If it sees an entry
that matches that file, it adds it to the resulting "_2" status file.
It handles adding entries to an existing section if already present in
the new status file. Otherwise, it adds a new section at the end with
the entries.
R=bkonyi@google.com
Review-Url: https://codereview.chromium.org/2989033002 .
This required munging a bit of test.dart code too to tease out some
dependencies, but the changes are minor. I considered moving all of
test.dart out into a package and making the status file library a
public one that other packages in the repo could import but this seemed
like the less intrusive change.
R=bkonyi@google.com
Review-Url: https://codereview.chromium.org/2984203002 .
