This changes the way the 'augment' modifier is handled in the parser.
Instead of being special cased for class declarations, it is now a
built-in identifier recognized only when the scanner is configured to
support augmentation libraries.
The change supports the used of the 'augment' modifier on not only
class declarations but also mixin and member declarations, as needed
for supporting macros.
Change-Id: I2679d198dea360900cfc478fae9c1660702a8a02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233887
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for the generating a synthesized augmentation
library for each library in which phase 1 macros were applied.
Current implementation piggybacks on the patch library support. The
intension is that both patches and augmentations are handled through
the same general mechanism. For now, the wording refers to augmentation
libraries as patch libraries where the implementation is shared.
Testing is extended to verify that the generated classes are
included in the resulting AST.
Change-Id: Ie0d4cfdc84b55ca87e0014794f14b38e442f08eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233101
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Cases where `null` was being passed as an argument to formatting a
message have all been fixed in previous CLs; all that remains to do is
change the type system to reflect that, and insert `!`s in a few
places.
This brings us one step closer to being able to make analyzer message
formatting type safe.
Change-Id: Id9e0d0b32f29cde0fdc5227417b7a2e3fc3b443d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216272
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change standardizes most of the analyzer to refer to problem
messages and correction messages using the names `problemMessage` and
`correctionMessage` (consistent with the naming convention used in the
analyzer and CFE `messages.yaml` files).
Change-Id: I72f078a368c65b346626f560cc721fcff4836452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215151
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change updates the classes Message, MessageCode, Template,
LocatedMessage, and FormattedMessage so that they uniformly refer to
error message text using the terminology `problemMessage` and to
correction suggestions using the terminology `correctionMessage`.
This brings them into alignment with the names we've decided to use to
unify the structure of front_end and analyzer, and makes them match
the names used in the anlayzer and front end's `messages.yaml` files.
Change-Id: Idcbb7ccfff6bb4e99ca22a3ef3c19d83880cf3c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215154
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. if reporting a missing ";" after a SyntheticStringToken (e.g. a
inserted identifier) before this CL it would go to the next token and
say we expected the ";" after that, when really we expected it *before*
that token.
Change-Id: I2c358e017edb2f661e307eba03dddaee889086d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205799
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Some notes.
1. `Token.next` is `Token?` because there are null(s) for comment tokens.
But I think that it is never `null` in code, because there is at
least EOF token. So, lots of `!` null checks.
2. `Link.tail` is never null when `isNotEmpty`, but the type system
cannot express it. So, some number of `!` null checks.
3. I keep assert(s) for now, and use comment
`// ignore: unnecessary_null_comparison`.
4. I disabled `can_get_rid_of_nnbd_issue_error`, I think it fails
because of changes in `_fe_analyzer_shared` language version.
Smoke test in google3 looks green.
https://test.corp.google.com/ui#id=OCL:346825148:BASE:346841611:1607632317129:6e87bf7
I have not tried yet full TAP, will do in the evening.
I have not tried yet Golem, or looked at benchmarks.
Change-Id: I651301e5d3a851dd77d73af960dac779cb0fc991
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175620
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
It started as a way to speed up IgnoreValidator, becaus computing
uniqueName as a concatenation of 'runtimeType' and 'name' was expensive.
We solved it in a better way, but I think this change is still useful.
Change-Id: I7d3cb8c91f4ca27a0aa3b93f8572cf12c6757bae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174322
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
* Add mechanisms to try out a recovery and only perform it if is
successful.
* Recover written out binary operators, e.g. "a xor b", "a or b" etc.
This fixes#26810 and is also how these operators are written in e.g.
Kotlin. This might be somewhat controversial though.
* Adds a mechanism to _replace_ a token by another token.
This might be controversial.
It is done because just inserting the operator causes the same rewrite
to be attempted on the same token stream several times (at least with
the way the token stream is parsed via the CFE) in turn causing it to
be recovered *sometimes*. This is now avoided by actually replacing
the token.
Change-Id: Icfa806045575d2aa2e5f35126708651b275bcf84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162003
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If an identifier starts with a non-ascii-character and has a comment
an assert was triggered about the comment not being attached to the
token. This CL attaches the comment to the token (which it should be)
and thus avoiding the assert trigger.
Change-Id: Id261970b88ca721d4b3a996abfb8ff43f0ec8341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161102
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit bc4893a3b3.
The previous attempt failed because when we check if something is a
conditional expression we used a rewriter that didn't actually rewrite.
This further down the line (still checking if we can parse the expression)
results in errors occurring (that wouldn't have occurred if the rewrite
had happened) and the conclusion was thus that it wasn't a conditional
expression and we parsed it as a null-aware index operator (which gave
errors because it wasn't).
This 2nd try solves it by having a rewriter that actually rewrites,
but then allows to undo the rewrites after we're done parsing.
Change-Id: Ide3c0d6a870d4dc18b6d9475b0227d93c733dc7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136624
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Johnni Winther