This doesn't actually run DDC to generate the web errors yet, but it
changes the CLI in anticipation of that, and adds tests to verify that
once web errors are reported that the updater handles them correctly.
Change-Id: I31264e3d468969b07f9eb60353a9b02a93bec7ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155102
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Auto-Submit: Bob Nystrom <rnystrom@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>
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>
This rarely comes into play because most static error markers don't
have an explicit line number. (This is by design so that shifts don't
cause diff churn.) But in some cases, the line number is written. When
that happens, the number may be wrong because previous added or removed
errors can shift the output line from where the original error was
reported.
Compensate for that. Fix#37990.
Change-Id: Ie306465c11d3b6a1de5ed158ad63167b4a5d4797
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114594
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>