This should make sure that everything that has to be initialized is in
fact initialized for doing expression compilation.
Change-Id: I89016b2e1b4f679c34c5450bcc56da28177728f2
Reviewed-on: https://dart-review.googlesource.com/71980
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Change a pair of package tests that relied on the existence of the
VM's Dart 1 platform Kernel binary. Use the Dart 2 platform instead,
becuase the VM will stop supporting Dart 1 in the future.
Change-Id: Ic93488974d9ed53cd205dcc24e0455a26b5f71b2
Reviewed-on: https://dart-review.googlesource.com/71246
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This CL is a result of discussing the Fasta implementation principles
with ahe. Following his advice this CL eliminates some unnecessary
closures that were meant act as plain aliases.
Thanks to ahe for kindly explaining Fasta implementation principles.
Change-Id: I0f0cb3dec211d686b193b3b1feafaa684606994b
Reviewed-on: https://dart-review.googlesource.com/71985
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
The signature of the overridden method buildCompoundAssignment in
KernelUnresolvedNameGenerator (c.f. kernel_expression_generator.dart)
was illegal, because its (named parameter) arity was four, whilst the
same method in one of its supertypes has arity five.
Furthermore, there was a signature conflict for
buildCompoundAssignment amongst the supertypes of
KernelUnresolvedNameGenerator:
KernelUnresolvedNameGenerator
extends KernelGenerator
|
= Generator with KernelExpressionGenerator
|
arity(buildCompoundAssignment) = 5
with ErroneousExpressionGenerator, UnresolvedNameGenerator.
|
arity(buildCompoundAssignment) = 4
In this CL the conflict is resolved by the "greatest common
denominator" approach, that is, now each implementation of
buildCompoundAssignment has arity five.
This CL is a necessary step towards fixing
https://github.com/dart-lang/sdk/issues/34235
Related change: https://github.com/dart-lang/sdk/commit/c95ef874aa5f3231bcd0560e86ccc03bc5a49839
Change-Id: If1992b8fb2bb994f83557c48fb0ac276b2d1a8d3
Reviewed-on: https://dart-review.googlesource.com/71520
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
According to the specification (§10.9) it is a compile-time error to
extend, implement, or use FutureOr as a mixin.
Expands the "multiple implements" check to include a test for whether
a class attempts to extend or implement the 'FutureOr' class.
The mixin case is indirectly caught by another syntactic check for
mixed in types (c.f. checkSemantics method in source_loader.dart). It
verifies whether a mixin has zero constructors. Since FutureOr has a
constructor the check fails. This is technically enough to meet the
specification, but it leads to a confusing error message for this
particular case. To improve the quality of the error message, we may
want to merge some of the mixed in check into checkSupertypes in
kernel_class_builder.dart.
Closes https://github.com/dart-lang/sdk/issues/33744
Change-Id: I887ea9431fd50059399937f4236523ed917e3673
Reviewed-on: https://dart-review.googlesource.com/71141
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL fixes handling of the following erroneous assignments:
- Compound assignment to postfix increment (e.g. "x++ += y;")
- Null-aware assignment to postfix increment (e.g. "x++ ??= y;")
There is some code duplication in ContextAwareGenerator now; I will
clean that up in a follow-up CL.
Change-Id: If68bc267b67904562bf8c2e705123d04fdf0b69a
Reviewed-on: https://dart-review.googlesource.com/71321
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It is a compile-time error if an interface appears multiple times
across the extends and implements clauses.
This CL implements a check to detect the aforementioned case. A
previous commit implemented this by expanding and refactoring the
restricted super types check in source_loader.dart
(c.f. checkSemantics method). The restricted super types check decides
whether a type is allowed to appear in an 'extends', 'implements', or
'with' clause. However, it turned out it may have sat too early in the
compilation pipeline as it failed to detect the following case
class A implements Object {}
I decided that it was somewhat suboptimal to implement a special case
for "Object". Therefore I have moved the check to a later stage in the
pipeline, where classes without a super class have had the Object
class injected as their default super class. The check is now
implemented in kernel_class_builder.dart (c.f. checkSupertypes
method).
Closes https://github.com/dart-lang/sdk/issues/34193
Change-Id: Ie7153c896337b589118cac4b80e9df8ea5a09daa
Reviewed-on: https://dart-review.googlesource.com/70864
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
These cases don't appear to be exercised by language_2 tests, so no
language_2 tests are fixed by this CL. I've added test cases to the
analyzer's driver_resolution_test to validate the fix.
Change-Id: I4a364e78f95981e94b51cf94d6f3236b022d42b8
Reviewed-on: https://dart-review.googlesource.com/71229
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
non-const constructor.
This CL also slightly improves the quality of the error message for
when a const constructor redirects to a non-const super constructor.
Note the two redirection checks are implemented in separate parts of
the code base. The former is implemented in finishConstructors in
kernel_target.dart, whilst the latter is implemented in
buildSuperInitializer in body_builder.dart. It might make sense to
localise them.
Closes https://github.com/dart-lang/sdk/issues/34161
Change-Id: Id9db06aaba9b5a330e22ea328d0ae60f104dfdcf
Reviewed-on: https://dart-review.googlesource.com/71165
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Previously we used the same code to handle returns and yields. The
code can be inlined and specialized. This is a change in preparation
for detecting invalid returns in ClosureContext.handleReturn instead
of in TypeInferrer.ensureAssignable.
Change-Id: Ia6adc43ac1b95bb684e5df3757bcfd253434396a
Reviewed-on: https://dart-review.googlesource.com/71248
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
There are some invariants about this class and some improvements we
can make:
* needImplicitDowcasts is always true
* returnContext is never null so neither is declaredReturnType or
expectedType
* ensureAssignable calls greatestClosure on the expected type so we
don't have to
* we don't need to unwrap the type of the subexpression unless we
are inferring a return type based on it
Change-Id: I4eaf41f17dd9d5ad44143a04ef02fe11824b2aa7
Reviewed-on: https://dart-review.googlesource.com/71164
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Error recovery generates a slightly different kernel representation
for "= x" inside a class method vs. outside a class method. Inside a
class method, the synthetic LHS is a property access; outside a class
method it is a variable access. The "outside a class method" case was
addressed in 55aa031404f36d181daf5f5b27424da431ee2e3e; this CL
addresses the "inside a class method" case.
Fixes 1 language test with [ $compiler == dart2analyzer && $fasta ].
Change-Id: Ib9429cac13b775a7d0b40a13468117c442611531
Reviewed-on: https://dart-review.googlesource.com/71223
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a bunch of renames and cleanup in preparation for
my next CL with basic mixin declaration support.
Rename listener events:
* handleClassImplements to handleClassOrMixinImplements
* beginClassBody to beginClassOrMixinBody
* endClassBody to endClassOrMixinBody
Rename parser methods:
* parseClassMember to parseClassOrMixinMember
* parseClassBody to parseClassOrMixinBody
* skipClassBody to skipClassOrMixinBody
Also:
* Change test expect from "ClassBody" to "ClassOrMixinBody"
* Rename message ExpectedClassBody to ExpectedClassOrMixinBody
* Update text of MISSING_CLASS_BODY to include mixin
* Rename IdentifierContext.classOrNamedMixinDeclaration to classOrMixinDeclaration
Change-Id: Iaa554cc859e1e665475c0eb544895a311c06395a
Reviewed-on: https://dart-review.googlesource.com/70881
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Specification disallow name conflicts between
- type variables and class names
- type variables and getter names
- type variables and member names
Although not present in current specification, the language team confirms that
it is also supposed to be a compile-time error if there is conflict with a setter.
Closes https://github.com/dart-lang/sdk/issues/33827
Bug:
Change-Id: Ia25bc91c3287f93ae43faae121a1f9d81b179c6b
Reviewed-on: https://dart-review.googlesource.com/70500
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This is a step toward fixing test arg_param_trailing_comma_test/166
with [ $compiler == dart2analyzer && $fasta ], since parser error
recovery handles that case by producing an assignment with a synthetic
LHS.
Change-Id: I5c998d335758d79dc0f13988c259b85e87051a08
Reviewed-on: https://dart-review.googlesource.com/71041
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This required introducing a new generator type to represent a
non-l-value, so that we can re-use the machinery of DelayedAssignment.
Fixes 6 language_2 tests with [ $compiler == dart2analyzer && $fasta ].
Change-Id: Ida2985df6d798d5466948e5de3dce5c17c2de7ac
Reviewed-on: https://dart-review.googlesource.com/70842
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The rules for void are changed to allow uses of void where we
previously had a warning, such as the case of assignment to a
variable of type void or passing as a parameter of type void.
Change-Id: I1c1513b0000fa1c8eedbe2645fab503b28024fa3
Reviewed-on: https://dart-review.googlesource.com/70265
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
To ensure that the resolution of the class name is communicated to the
analyzer, we take advantage of SyntheticExpressionJudgment.original,
which allows us to ensure that type inference is performed on a
synthetic read of the class name expression. This causes the
appropriate information to be communicated to the analyzer, and then
at runtime the value produced by the synthetic read is discarded.
Fixes 15 language_2 tests with [ $compiler == dart2analyzer && $fasta ].
Change-Id: I02ad23acbb64c297129f59ff56171399bf067c33
Reviewed-on: https://dart-review.googlesource.com/70780
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Bug: https://github.com/dart-lang/sdk/issues/33022
This commit adds an error when a final field is not initialized at all
(and there is at least one generative constructor). A later commit
will add an error for the case where a field is initialized by some,
but not all, generative constructors.
A number of classes in the Dart2js and DDC support libraries use
uninitialized final fields to indicate getters in the corresponding
native classes. This commit adds a temporary whitelist for the
affected files, which can be removed when the fields have been
replaced by external getters.
This is tracked by https://github.com/dart-lang/sdk/issues/33762
Change-Id: I6b5cee230c7cd5554da2b61da7ebddb6b0b9396e
Reviewed-on: https://dart-review.googlesource.com/63781
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Before this CL, if initializing from a dill file containing a class,
say A, but it wasn't used, and then later using it as a type, say
'A a = new A()', the class hierarchy would complain about not knowing A.
This was caused by the class hierarchy initially being constructed using
the full component of the first compile (i.e. in the example above
without any usage of A and thus without including A), and subsequent
compiles telling the class hierarchy about new classes created in that
compile. The problem was, that if the class was loaded from a dill file
(in the example above 'A' was such a class) it would never be included
if not a part of the first full component.
This CL fixes it by changing the interface to the class hierarchys
`applyTreeChanges` function and letting the class hierarchy know about
libraries too: It will now basically just be given the full component
when asked to update, and just update with the libraries it doesn't
already know about. In the example above that would - once using 'A' -
include 'A'.
Change-Id: I895100b51659938636da0bca6c80516d87b57a24
Reviewed-on: https://dart-review.googlesource.com/69302
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Extends the illegal return type check for async functions to cover
illegal return types for functions marked async* or sync* as well.
Adds new error messages for illegal return types of functions marked
async, async*, and sync*. These error messages conform with those
produced by the analyzer.
Closes https://github.com/dart-lang/sdk/issues/33068
Bug: www.dartbug.com/33068
Change-Id: I6d8690537139d3d094a4e295fcac9de4f4a7f0af
Reviewed-on: https://dart-review.googlesource.com/69581
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Jens Johansen