We now no longer need the `expr2` function to test expressions whose
type is RecordType.
Also added unit tests of the type parser in mini_types.dart (which was
previously tested only by virtue of its use in other tests).
Change-Id: I5d351f3ff924676b4d84e65c8949f42feca0dab9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267522
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The NamedType class in mini_types.dart doesn't really represent a type
in the same way that the other subclasses of Type do; it's simply a
pairing of a name and a type.
Change-Id: I20709e66a44da4afbf187984c2032b315c1cc21e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267287
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Not sure if this is has much value in comparison to the existed
implementation in the analyzer.
We also have private implementations for extractor and record
patterns in the analyzer. I don't know yet for sure how (if) we will
share these, but if we do, it might be something like this one.
Change-Id: I86070bcf922a58fbf1087c7ab42c6eb5695c1475
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266861
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This revisits the validation after the redesign. The changes from
before the redesign include:
- Accounting for multiple extensions on @staticInterop classes
- Users can implement any of the extension members for a given
export name, with the exception that if there is a getter/setter
pair, both should be implemented if any one of them are
- Since this validation goes on top of exports, the Dart class
needs not be processed, and we use the same export creation process
to create the mock
Change-Id: I05a7cff765d6d37d3955dd93676e2d55d2b201b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/262862
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Creates an external createDartExport function in js_util.
Adds a number of checks for the annotation:
- Classes with the annotation should not have value in the annotation
- Classes with the annotation should have at least one instance member
somewhere in the hierarchy
- There are no export name collisions that are unresolvable accounting
for overrides
- Members with this annotation are instance members with a body only
Also adds checks to createDartExport:
- Checks that the type is a Dart class
- Checks that the type is marked as exportable
Change-Id: I52f27275966e9603e88921ce7897b7615178c4d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259511
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This add the Expression-, Binary-, Cast-, NullAssert-, NullCheck-, List-
and RelationalMatcher and creates these during body building. The
IfCaseStatement is added to support propagation of these to the
inference visitor.
Change-Id: Ia9add15e504cb06af711efc1697a00b8e235e1a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/263128
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
There was no need for both of these listener callbacks, because they
were always called together. Since `beginCaseExpression` is actually
used, it makes sense to keep `endCaseExpression` and get rid of
`handleCaseMatch`.
Change-Id: I544096b2c2b2814e8cc0c8606455855cb77c9e60
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264102
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* required is a modifier when followed by [record type] `?`.
* Parse record type as record type if followed by `super` or `?` `super`
or `?` `this`.
* Typedef with record type follow by `?`.
* Parse record type as record type in get/set with async/sync/sync*.
* Parse record type as record type when followed by `>>=` or `>>>=`
(for weird formatted use in typedefs).
Change-Id: I19e208497e28780fb1505139c488e943751cce25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/263123
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This change restores `parseParenthesizedExpressionOrRecordLiteral`,
`parseArguments`, and `parseArgumentsRest` to the way they looked
prior to adding parser support, and instead adds new methods
`parseParenthesizedPatternOrRecordPattern` and
`parseExtractorPatternRest` that are specialized for patterns parsing.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I104e031a796ef7f217cd427e1a9ae94a04dafa7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261620
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The parser now supports the following subset of the parser grammar:
- logical-or and logical-and patterns (called "binary patterns" to
reflect analyzer nomenclature)
- extractor patterns
- cast patterns
- list patterns
- map patterns
- null-assert patterns
- null-check patterns
- variable patterns where the variable is preceded by `var`, `final`,
<type>, or `final <type>`
- if-case statements (and if-case within collections); without guards
- record patterns
- parenthesized patterns
- constant patterns where the constant is a plain expression not
beginning with `const` (booleanLiteral, nullLiteral, numericLiteral,
stringLiteral, identifier, or qualifiedName).
- relational patterns
- patterns in switch statements
- integration with the analyzer's AstBuilder class
Not implemented yet:
- constant patterns beginning with `const`
- variable patterns where the variable is a single identifier (note:
this means that `_` is currently interpreted as a constant pattern
rather than a "wildcard" variable pattern)
- guards (a.k.a. "when clauses")
- switch expressions
- pattern variable declarations
- patterns appearing in "for loop parts"
- pattern assignment
- several error checking and error recovery scenarios (see TODO
comments)
- integration with the front_end's BodyBuilder class
- front_end style parser tests (currently the feature is tested using
analyzer unit tests only)
Note that in patterns, `as` binds has higher precedence than `&` and
`|`, whereas in expressions, `&` and `|` have higher precedence than
`as`. To reflect this, a new precedence has been added,
CAST_PATTERN_PRECEDENCE.
To reduce the risk to users during parser development, the parser
currently only attempts to parse patterns when instructed to do so
(i.e. when the language feature is enabled). In the long term, I
intend to change the parser so that it always attempts to parse
patterns, and it is the responsibility of its listener to report
errors if patterns are used without enabling the language feature.
Change-Id: I360b535d2a6ebd35a0ee4d066b06e3ae8e3121ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261020
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For ease in code review, I've made all the changes that affect test
expectations files here, in a way that can easily be confirmed during
code review to have no functional effect on parser semantics.
This will be followed by a change that introduces parser support for
patterns, but doesn't affect test expectations.
Change-Id: I830600c1ae89447c7745bfae6fd91c379b6e05d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261022
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL uses Martins suggested fix (adding 1 to avoid shifting a
negative), and adds a simple test that compiles the parser to dart2js
(with asserts enabled) and runs it via d8. This will perhaps catch
breakage up front another time.
To my knowledge this is not a supported use case though, so likely
we can't but in much effort for any future big breakages.
Fixes https://github.com/dart-lang/sdk/issues/50048
Change-Id: Ic5ac6e63f2d6d32e38ba562ed21dbe85328935cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261301
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Patterns may need to be visited twice during analysis: once to
determine a type schema, and a second type to resolve the pattern
match. Previously, the shared TypeAnalyzer had just a single
`dispatchPattern` method, so it had to create temporary objects to
record the structure of the patterns between the two visits. Now,
there are two dispatch methods: `dispatchPatternSchema` and
`dispatchPattern`. This avoids the creation of a bunch of temporary
objects and makes the design much simpler.
(Based on an idea from Brian Wilkerson)
Change-Id: If10b6b7fb578594c3f660baa55d7e28123652638
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260282
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov