Currently only CFE ("Fasta") tests have their context message output
parsed. It should be easy to extend that to dart2js and DDC if that's
useful. Analyzer might be more work.
This also adds support to the test updater for inserting context
messages when updating tests. By default, that flag is off, so the
existing behavior is preserved where context messages are ignnored. If
you want them, pass "-c" when updating a test.
When validating test output, if the test file contains context messages,
then they are validated. Otherwise, any context messages in the CFE
output are ignored. This way existing tests still pass.
Change StaticError to represent a single error for a single front end.
Before, the data model collapsed errors for different front-ends at the
same location into a single StaticError object which tracked different
messages for each front end. The idea was to move towards a world where
they really are the "same" error with eventually the same message.
But this adds a lot of complexity with things like merging errors and
doesn't reflect the reality that each error from each front end is
basically its own thing. Also, critically, it makes it much harder to
attach context messages to a specific front end's error object.
This changes it so that an instance of StaticError represents a single
error for a single front end. The test file syntax is unchanged and the
updated tool behaves the same. In a static error test, multiple
expectations can still share the same "// ^^^" marker line. They are
just expanded to multiple StaticError objects at parse time.
This eliminates all of the complexity around merging and simplifying
errors.
Change-Id: Ida1736bfcde436fc2d1ce2963d91fa9cb154afa8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193281
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Before, the data model collapsed errors for different front-ends at the
same location into a single StaticError object which tracked different
messages for each front end. The idea was to move towards a world where
they really are the "same" error with eventually the same message.
But this adds a lot of complexity with things like merging errors and
doesn't reflect the reality that each error from each front end is
basically its own thing. Also, critically, it makes it much harder to
attach context messages to a specific front end's error object.
This changes it so that an instance of StaticError represents a single
error for a single front end. The test file syntax is unchanged and the
updated tool behaves the same. In a static error test, multiple
expectations can still share the same "// ^^^" marker line. They are
just expanded to multiple StaticError objects at parse time.
This eliminates all of the complexity around merging and simplifying
errors.
Change-Id: I1d55a6e885e12cc9c438f928297fc0db7dd5ce85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193280
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
If a static error test only has expectations for *warnings* then it
still has well-defined runtime semantics that we want to test.
This distinguishes those tests and runs them on non-front-end
configurations.
Change-Id: I41b8d84a229ba53ad0db0271b28a9b9482ad582d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155305
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Karl Klose <karlklose@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This enables parsing and validation for tests that contain:
// ^^^
// [web] Some web-specific error.
This doesn't run those tests on DDC and dart2js yet, and the test
updating tool doesn't handle web tests yet. I'll do those in follow-up
patches.
Change-Id: Id06397a20a06c00e48801a16c01d5878e0264f6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146462
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Both a test file and now a test configuration can specify that
experiment flags should be enabled. Since they both can, passing those
to the tools is a little tricky because we need to merge the two
command line arguments. It's made worse by the fact that this corner of
test_runner is riddled with poorly factored code.
This doesn't fix the redundant code, but does merge and pass the flags
through. Right now, it parses them from the test file by looking for
them in the SharedOptions line, which is where they currently appear.
That's pretty hacky. Eventually, we should change these tests to use:
// Requirements=
Fixes#38386, #38387, #38388, and #38389.
Change-Id: I1aea1482b30b9ba19c427319f895822d81ee12ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121262
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This gives us a way to specify that a test is only meaningful for
certain NNBD modes and should be skipped on other configurations. My
hope is we can extend this for other platform capabilities and then
eventually use this to express "skips" instead of relying on status
files for them.
Change-Id: I99548c326ee6fbe6db64e28e7f7f07d2fc1fd23c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117080
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
- Make it synchronous. I did some benchmarking and the async didn't seem
to make a measurable difference and made the code harder to follow.
- Fix a bunch of small-scale idiom things: "var", names, etc.
- Move TestCase.hash into TestFile since that lets us access it before
we've created a TestCase.
- Remove dead code.
- Make it clearer which functions work with TestFiles and which with
TestCases.
- Clarify the code that determines whether or not to enqueue a test.
The last point is the motivating one. Soon, I'll be extending this code
to take NNBD into account when determining which tests to skip, so I
wanted to clean it up some first.
Change-Id: I488ed6c7d2453535968ac43389a2fd8370ead57d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116662
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
The CFE currently does not report the length in an error location, just
the starting position. When the static error update tool inserts an
error marker for an error reported only by the CFE, it doesn't know
what length to use.
It used to deal with this by always writing an explicit error location
like:
// [error line 1, column 9]
Those are kind of ugly and brittle, though. This changes it to treat
the error as implicitly having length 1. This way, it can just output:
// ^
When validating an error expectation against a report CFE error, the
length is ignored anyway (since the CFE doesn't report it). In order to
ensure that the parsed output of the tool matches the reported data that
produced it, the parser also ignores the length when parsing an error
expectation for a CFE-only error with length one.
Fix#37991.
Change-Id: I20e109142546b7e82a5f796a1a40613b90dc89bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114745
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The previous system let you use this to define an "unspecified error":
int i = "bad";
// [unspecified error]
The marker comment meant that *both* front ends had to report some error
on the previous line, but any error at any position was considered
acceptable.
Unfortunately, this doesn't let us incrementally specify an error for
one front end while leaving it unspecified for the other. This means
that when, say, the analyzer implementation lands first, we can't pin
down its errors while still leaving the CFE errors unspecified until
its ready.
This addresses that by making "unspecified" a property of each front
end, not the error itself. The new syntax is:
int i = "bad";
// ^^^
// [analyzer] unspecified
// [cfe] unspecified
This means the same thing as the previous example: both front ends must
report some error on the previous line. The column information is
authored as a best effort, but ignored.
Now, let's say the CFE implementation lands. The above can be changed
to:
int i = "bad";
// ^^^
// [analyzer] unspecified
// [cfe] Real error message.
At this point, the CFE test must report that exact error at that exact
position and message. But the analyzer is still free to report any
error code anywhere on that line.
This syntax is a little more verbose, but it's simpler and more
flexible.
Change-Id: I37f937d245fd8ec8054acb6128256f9fff6241e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/109728
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
If a test has the static error markers and is run on analyzer, the
test runner verifies that the reported errors exactly match the expected
ones. A test with error markers is skipped on all other configurations.
Change-Id: Ib921acde517688f5b47937a5b100c0507e0e9138
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107823
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Robert Nystrom