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>
The new name, `handleMergedStatementCase`, is more consistent with the
rest of the type analyzer's `handle` methods, and more accurately
describes when the method is called (after a switch body that's
potentially shared by multiple case heads and possibly a `default`
clause).
Change-Id: I4f3166d5f58432f9f1cc0edffb3c0a317539ea23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260064
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Support for the following pattern types is added to the (as yet
unused) shared type analysis prototype:
- Cast patterns
- List patterns
- Logical-and patterns
- Logical-or patterns
- Null-assert patterns
- Null-check patterns
- Wildcard patterns
Change-Id: I923df94b5deef925ca94e6ff0c8eac0493f69c1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257602
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- `CaseHeadInfo` is renamed to `CaseHeadOrDefaultInfo`, to reflect the
fact that it is used for both case heads and default clauses.
- `CaseHeadOrDefaultInfo.node` is no longer needed; this used to be
used for error reporting, but after the refactor of
https://dart-review.googlesource.com/c/sdk/+/259021 is was no longer
used.
- `ExpressionCaseInfo` is renamed to `SwitchExpressionMemberInfo`,
consistent with the AST structure `SwitchExpressionMember` in the
analyzer.
- `SwitchExpressionMemberInfo.body` is renamed to
`SwitchExpressionMemberInfo.expression`, consistent with the
nomenclature used in the analyzer.
- `StatementCaseInfo` is renamed to `SwitchStatementMemberInfo` for
consistency with `SwitchExpressionMemberInfo`. Note that the
analyzer calls its corresponding AST structure `SwitchMember` rather
than `SwitchStatementMember` for legacy reasons.
- `SwitchExpressionMemberInfo` no longer extends
`CaseHeadOrDefaultInfo`; it contains a pointer to the head or
default info. This is more consistent with
`SwitchStatementMemberInfo`.
Change-Id: I727766a6f0601ec5cd8aff824364319a54446bd2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Bug: https://github.com/dart-lang/sdk/issues/49351
Adds checks for the following cases:
- Type arguments to createStaticInteropMock are correct
- No missing members in implementing class
- Inherited and non-overridden @staticInterop members are implemented
- Dart class can implement through inheritance and mixins
- Implemented members are correct subtypes of @staticInterop members
- Potential extension member conflicts that are attempted to be
resolved through subtyping rules
Change-Id: Iacbe5846040ba7fab41459aa19be77351cf1efca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255761
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Make the following changes, based on
https://github.com/dart-lang/language/commit/8a9b9a8a74a49e13c625e5208bab201d8a4f0e76:
- Replace `ConstOrLiteralPattern` nomenclature with `ConstantPattern`
(the spec no longer speaks of "literal patterns").
- It is an error if a guard's type is not assignable to `bool`.
- Variable patterns can now be `final`.
- We now have a separate error condition to cover the case where a
variable, list, map, record, or extractor pattern appears in an
irrefutable context and the matched type is not assignable to the
required type of the pattern. (Previously such patterns were simply
called "refutable", leading to a less clear error).
Additionally, we now consistenly use the term "guard" to refer to the
expression after a `when`, consistent with the spec text.
There are a few new TODOs, which I plan to address in follow-up CLs.
Change-Id: Ia0abab9492583f2aa8b59a9b381b90ba11b3e0fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259246
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change refactors the logic for detecting overlapping and missing
variable patterns so that it can be invoked prior to the rest of type
analysis, rather than during it. In addition separating concerns
nicely (since no types are involved in these checks), I believe this
will facilitate integration with the analyzer and front end, by
allowing them to detect these errors and find the unique set of
variables defined by a pattern, at the time they are resolving
identifiers to their corresponding declarations.
Change-Id: I40879fca46d39e78a60813db007983e57a3aec31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I've begun prototyping what it might look like to integrate the
current shared type analysis functionality with the analyzer and CFE,
and I've discovered some API improvements that are needed:
- The shared logic now handles the possibility that switch cases that
share a body have been merged prior to type analysis (because the
CFE merges them during parsing), in addition to the pre-existing
functionality which assumed that switch case merging had to be done
in the shared logic.
- The shared logic now returns several pieces of information as the
result of a call to `analyzeSwitchStatement`: whether the switch
statement had a `default` clause, whether it was exhaustive, whether
the last case body terminates, and the type of the scrutinee. These
are all needed by the CFE.
- The shared logic now allows `TypeAnalyzer.errors` to be `null`,
indicating that no errors should be reported. This reflects how
errors are suppressed during top level inference in the CFE.
- If a switch case lacks a `when` clause, this is reported by calling
`handleNoWhen` rather than passing a boolean to `handleCaseHead`.
- The shared logic now reports the appropriate error when a case
constant doesn't properly match the scrutinee's static type.
- Information about case labels is now delivered to flow analysis via
`switchStatement_endAlternatives` rather than
`switchStatement_beginCase`. This made it possible to rewrite the
shared `analyzeSwitchStatement` method in a way that requires less
bookkeeping, because it no longer has to peek ahead to look for
labels associated with a given case body.
- `TypeAnalyzer.analyzeExpression` is now responsible for
understanding that "no context" and a context of `dynamic` should
both be coalesced to `?`. The analyzer does this (although it's not
100% why), and it's definitely "business logic" that eventually
belongs in the shared type analyzer.
- `TypeAnalyzer.analyzeSwitchExpression` and
`TypeAnalyzer.analyzeSwitchStatement` no longer receive a list of
ExpressionCaseInfo / StatementCaseInfo objects describing the cases;
instead they query for them using a callback. This reduces the
lifetime of the ExpressionCaseInfo / StatementCaseInfo objects. In
the future, when we have record support, we could replace these
objects with records, which would then be passed on the stack,
avoiding any allocations.
- A new hook, `handleSwitchScrutinee`, is called right after visiting
the "scrutinee" expression of a switch expression or switch
statement. This hook is needed by the analyzer to compute
exhaustiveness. In a future CL, I hope to move exhaustiveness
analysis into the shared code as well, which should make this hook
unnecessary.
- `TypeAnalyzer.analyzeSwitchStatement` now reports an error if a
switch case completes normally and pattern support is not enabled.
- The test class `_MiniAstTypeAnalyzer` no longer overrides
`analyzeExpression` to provide a default context type; instead,
every call to `analyzeExpression` that didn't previously provide a
context now provides a context of `?`. Note that not all of these
are correct, but they are close enough for the unit tests we have
today. I plan to fix them in future CLs as I replace this logic
with shared logic.
- The hook `handleVariablePattern` is now always provided with a
static type. Previously, it was only provided with a static type if
this was the first time the variable was bound in the pattern.
Change-Id: I70e3c5468312a9329fcf4ad2e13749a32d2418e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257487
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Chloe Stefantsova