This caused deopt_ids to be wrongly reused when mixing
jitted and interpreted code.
Change-Id: I23eb93bb79d7297f8d9efdd81844394fee3fb821
Reviewed-on: https://dart-review.googlesource.com/71703
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
Thanks to Alex Markov for the test case!
Fixes#34269.
Change-Id: I66371532b40984c58332ee43c99e744d746ecfae
Reviewed-on: https://dart-review.googlesource.com/71540
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Generic closures should take delayed type arguments into account when
initializing type arguments in prologue.
Fixes language_2/instantiate_tearoff_test in bytecode mode.
Change-Id: I0ab07e759f3372ae9143a48f0b8b0fe4fab8a51a
Reviewed-on: https://dart-review.googlesource.com/71432
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
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>
If receiver is captured, the variable is duplicated so top-level
members can access receiver as a local variable.
This is more efficient and allows uses of receiver in the prologue of
top-level member, before context is allocated and receiver is copied to
the context.
Change-Id: I5b13f692767c3aa445e558bff2bc3f8fbf016561
Reviewed-on: https://dart-review.googlesource.com/71431
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
We already do this for static calls, with this CL we'll also do it for stub calls.
Change-Id: I2ec78a94165472d4a197f78a5789336b1b29e089
Reviewed-on: https://dart-review.googlesource.com/71402
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@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: c95ef874aa
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>
The current specification only prohibits expressions statements where the
expression *is* a map, not those that *start with* a map.
Implementations have always rejected those starting with a map.
Bug: http://dartbug.com/725
Change-Id: I805a6f82d1afdcf335aff73e74dac1f14e5a6afe
Reviewed-on: https://dart-review.googlesource.com/71247
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@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 getter appears to have been introduced in anticipation of
refactoring the summary mechanism to avoid populating summaries with
unnecessary "informative" data (see
da6a26966e), but such a refactoring
never occurred.
Change-Id: I6c486b21864b22a943af546a76bd63f7d55c42a3
Reviewed-on: https://dart-review.googlesource.com/71427
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
... with parser recovery added in subsequent CLs.
Change-Id: I7a73e8e2a4dee961920fe9854bcd108bb1041b20
Reviewed-on: https://dart-review.googlesource.com/70882
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
The getter used to be used to skip certain tests when testing the code
that computed summaries from the element model. That code was removed
nearly two years ago (d13a887292).
Change-Id: I03fe6a28d9064374e25e4968fb1d2780f75e6826
Reviewed-on: https://dart-review.googlesource.com/71440
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes#30187
Include description of behavior around when the Future completes and how
errors are handled. Include detail of ordering - since the default
`Set` implementation is `LinkedHashSet` where insertion order matters.
Change-Id: I4695c131bcab4527b153f57f90bffe61c818d187
Reviewed-on: https://dart-review.googlesource.com/71381
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Fixes#27756
Call out more explicitly in the `pause` doc that `resume` and
`resumeSignal` are interchangeable, and in both docs that a `resume`
call is safe on a subscription which is not paused.
Also reformat to remove single newline in between sentences and to 80
character lines.
Change-Id: I1efd05639400f2cb5266e686adb99c3c721fabe7
Reviewed-on: https://dart-review.googlesource.com/71380
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Prior to c95ef874aa, case 02 crashed the
front end. Prior to f074f3c120, case 01
crashed analyzer/FE integration. Prior to
a94e43af7c, cases 02 and 03 crashed
analyzer/FE integration. So it seems worth adding a test to make sure
we don't regress.
Change-Id: I0e1af7d9ed397d40dd1aebab3ff919999379d824
Reviewed-on: https://dart-review.googlesource.com/71369
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change-Id: Icaf6329729a17b20a591ae6e9b8bf7c0d2e21265
Reviewed-on: https://dart-review.googlesource.com/71368
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds checking of number of passed function type arguments into
prologue of generic functions in bytecode. If type arguments are not
passed, then default type arguments (instantiated bounds) are used.
This mimics IL generated in StreamingFlowGraphBuilder::BuildDefaultTypeHandling.
In order to implement this check, a new bytecode instruction
JumpIfNotZeroTypeArgs is added to bytecode generator and interpreter.
Fixes language_2/function_apply_generic2_test in bytecode mode.
Change-Id: I70901c16b8bfc5f86623d51fccaf50f8969c587e
Reviewed-on: https://dart-review.googlesource.com/71387
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reverted because of failures on the VM reload tests.
Change-Id: I880523a5f3e14cc6d318d4493f037b79515b1dce
Reviewed-on: https://dart-review.googlesource.com/71401
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Avoid using deprecated errors by hadling them on a case-by-case basis.
This is a version of https://dart-review.googlesource.com/c/sdk/+/63144
with merge conflicts resolved.
Fixes#33686
Change-Id: I726740af2db5d32f15c8103c903376bc8ea948e6
Reviewed-on: https://dart-review.googlesource.com/71161
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This follows the pattern of other meta-annotations, when it comes to the AST:
* Element gains a new `hasSealed` getter. Many overrides.
* ElementAnnotation gains a new `isSealed` getter.
Bug: https://github.com/dart-lang/sdk/issues/34232
Change-Id: If8ae8e16b500125cb3b92b3cf83d46de6ca6ee23
Reviewed-on: https://dart-review.googlesource.com/71227
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Some optimizations were checking for a number of successors of graph
entry - but that count includes unchecked entry and indirect entries.
Change-Id: Ib163a7710aaba3e68023a9cd04ca194c03262c33
Reviewed-on: https://dart-review.googlesource.com/71302
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
