Negative test cases
generic_function_type_as_type_argument_test/01
generic_function_type_as_type_argument_test/02
rely on a compile-time error, which is still missing in CFE.
Unlike default VM, bytecode pipeline does not flag this error.
Change-Id: I3c052b5ca6013ab0728ffc234b5ffbe2fddfec5d
Reviewed-on: https://dart-review.googlesource.com/71600
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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>
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>
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>
This fixes a crash in StackFrameIterator when using interpreter.
Prevent timeout in thread test when using interpreter.
Adjust kernel status file for known issue.
Change-Id: I9e28675a3532153df24456e65407a8ce73503928
Reviewed-on: https://dart-review.googlesource.com/71222
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@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>
It was badly converted to Dart 2, and was both using and testing things
that can no longer happen (like returning a non-null non-String value
from toString).
Change-Id: I085d1172f177e80c3f75af36a2028b7ea241713a
Reviewed-on: https://dart-review.googlesource.com/71144
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@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 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>
Clean out dart2js/ddc status entries that are subsumed by the generic
one for Fasta in language_2_kernel.status.
Change-Id: If70ae797384af488d816082a9d041d48ed6b5876
Reviewed-on: https://dart-review.googlesource.com/70280
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
Mark a few failures as expected, due to lack of line numbers in stack traces.
Move restoring of pool pointer out of inlined macro after exception.
Change-Id: I8ef1e0f86a1eabe42e007968481e0133d0e5e360
Reviewed-on: https://dart-review.googlesource.com/70741
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
We were attempting to "override" a failing test for the analyzer by
putting a "pass" annotation in a more specific section of the status
file. But that doesn't have the intended effect--it just means that
when the test is run for the analyzer, either a pass or a fail result
is accepted.
Change-Id: Iccd7e68c746e7989840c6d0e6ee16bd4f0677e2d
Reviewed-on: https://dart-review.googlesource.com/70163
Reviewed-by: Devon Carew <devoncarew@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>
In changing the proposed spec to address comments in a way that was intended to be
non-breaking, I accidentally introduced some new (unintended) restrictions. This
fixes the spec, rolls back the change in analyzer, and adjusts the language tests
appropriately.
Change-Id: I487b0eaacbfa1447d4ee909c0a56e435c2088990
Reviewed-on: https://dart-review.googlesource.com/70462
Reviewed-by: Mike Fairhurst <mfairhurst@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>
The scanner associates '<' with '>' and '>>',
but the parser cannot use '<'.endToken/endGroup reliably
and wastes time updating that token's endToken/endGroup field.
This CL updates type info parsing to ignore '<'.endGroup
and step through the token stream (which it has to do anyway),
for improved parsing.
This CL causes a handful of existing tests to fail (marked as @failingTest)
and test failures will be addressed in a subsequent CL.
Change-Id: I788e9a74cd2891f98f44bba15d5669febfec6c64
Reviewed-on: https://dart-review.googlesource.com/70001
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
async function return type check whenever running in 'legacy mode'.
Adapts language_2_kernel.status such that a MissingCompileTimeError is
expected for illegal return types of async functions when running in
'legacy mode'. Updates the commentary in finishFunction in
body_builder.dart.
Some legacy tests* have revealed that it may not always be correct to
check whether [strongMode] is enabled before checking the return type of
async functions. The reason behind the strongMode check was to ensure
that [_typeInferrer.typeSchemaEnvironment] would be instantiated as
per ahe's suggestion.
There seems to be some inconsistency in the code base as to when
[_typeInferrer.typeSchemaEnvironment] is non-null. For example, during
the fasta perf benchmarks one may observe a null value, whilst it
seems that the member is always non-null when running `dart
--no-preview-dart-2 <script.dart>`.
* test log: https://ci.chromium.org/p/dart/builders/luci.dart.ci.sandbox/front-end-legacy-linux-release-x64/621
Change-Id: I2211bfe0ae75a7aa35e2d698ff5cba27af484d07
Bug: 33425
Reviewed-on: https://dart-review.googlesource.com/69920
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
For most failures I've added a comment with a short description of the
failure. In a few places I've included a reference to an issue in the
issue tracker. I'll follow up with a CL that assigns issues to the
remaining failures (and I'll file issues if necessary).
I haven't tried to classify the "MissingCompileTimeError" or
"MissingStaticWarning" cases, since they are most likely due to
error/warning checks that haven't been implemented in the front end
yet, and that work is being tracked elsewhere.
Change-Id: I41559ed848a687767eb1018502cbbc104569a7cd
Reviewed-on: https://dart-review.googlesource.com/69880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
declared return type of an async function is a super type of Future<T>
for any T. In case the check is not successful an error message is
produced. The location of the name of the offending function
declaration is used as location information for message. Ideally we
would use the location of the type, so until types get annotated with
location information the error message remains suboptimal.
This closes#33425 and closes#34057.
Thanks to dmitryas and jensj for their helpful guidance.
Bug: dartbug.com/33425 dartbug.com/34057
Change-Id: I3b3dadc25b574422ea1f38671fe8cba3ffdd494c
Reviewed-on: https://dart-review.googlesource.com/69307
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Rationale:
This improves JIT and AOT performance of unary minus
and also improves constant folding and range analysis
on negative constant (viz. x / -3 is often x / - (3)).
The SHIFT operator needed some special treatment, since
we have to avoid converting a NON-speculative shifts
back into a deopt.
https://github.com/dart-lang/sdk/issues/34072
Change-Id: I230c9cfda98297f683bbba53688e57c2cc659360
Reviewed-on: https://dart-review.googlesource.com/68434
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Alexander Markov