browser-compat-data includes info on elements as both part of the
Web API and the individual tagged elements. The scripts would default
to whatever was processed last instead of trying to unify any conflicts
that may come up with the different sources of truth. This CL addresses
that issue by choosing the "stricter" of the two versions.
Change-Id: Id3437c14276faf8af3fe41d7a6eb83defc9bd0b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155844
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This adds a mechanism similar to that used in async functions where
exceptions are caught in the synthetic code and passed into the
generated body to be rethrow'n.
This ensures the exception is throw'n from the same place as the
original yield*, as per the spec.
Bug: https://github.com/dart-lang/sdk/issues/42466
Change-Id: I553dd89141985f6f30751913a1c8a62b1229af04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158543
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The sync operations on a MultiStreamController did not check whether
sending events at the current time was allowed.
That could lead to `null` dereferencing errors when doing operations
on the controller after a cancel, and could cause events to appear
out of order.
Change-Id: I06b86a78959dfcaa402f74e2980a9d515f097dc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159442
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Postfix increments and decrements are null-shorting expressions
(e.g. `x?.y++.isEven` only calls `isEven` if `x` was non-null), but it
is still being decided whether postfix `!` should be null shorting
(i.e. whether `x?.y!` should fail if `x` is null). See
https://github.com/dart-lang/language/issues/1163.
Previously, the analyzer was inconsistent about whether it considered
`!` to participate in null shorting; as a result, when analyzing an
expression like `x?.y!`, the analyzer would fail to call
`FlowAnalysis.nullAwareAccess_end`, resulting in corrupted flow
analysis state, which could lead to a crash.
This change makes the analyzer treat `!` as *not* participating in
null shorting, which is consistent with what is currently written in
the spec and implemented in the CFE.
Fixes#43093.
Change-Id: Ie69c5c29f226fe1a0282d0e7a1e079778dc700c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159147
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL performs the following checks in the invoke field dispatcher for
dynamic closure calls when lazy dispatchers are enabled:
* The provided function type arguments vector (if any) has the correct
length.
* No function type arguments should be provided if the closure has
delayed type arguments.
* All required arguments (positional in all modes, named in appropriate
null safety modes) have been provided by the caller.
* If there are optional positional arguments, an appropriate number
has been provided.
* If there are optional named arguments, their names are valid.
Since the runtime already handles checking the argument shapes when lazy
dispatchers are disabled, these checks are now completely removed from
closure bodies in all cases. Thus, the only remaining checks in closure
bodies are the type checks performed by AssertSubtype and
AssertAssignable when lazy dispatchers are enabled.
Changes in the Flutter Gallery:
* ARM7, release: -3.61% instructions, -2.19% total
* ARM7, sizeopt: -3.62% instructions, -2.55% total
* ARM8, release: -3.66% instructions, -1.98% total
* ARM8, sizeopt: -3.65% instructions, -2.37% total
Most of these changes are already exercised by existing tests such as
(but not limited to):
* corelib{,_2}/dynamic_nosuchmethod_test
* language{,_2}/call/call_test
* language{,_2}/closure/tearoff_dynamic_test
* language{,_2}/generic/function_bounds_test
* language{,_2}/parameter/named_with_conversions_test
* language{,_2}/vm/no_such_args_error_message_vm_test
I've added one test to specifically check the interaction between
dynamic calls and required named parameters. There is some coverage in
other NNBD tests, but those are not directly focused on testing this
specifically.
Other changes:
* Adds initial cached ranges for certain BinarySmiOp and ShiftIntegerOp
instructions when the RHS is a constant, to avoid false negatives for
deoptimization and throw checks prior to range analysis.
* Adds new slots for various Function fields.
* Adds the ability to define unboxed native slots, which are always
unboxed after retrieval even in unoptimized code. In the first
iteration, the backend only handles loads from Uint32 unboxed native
slots. Part of https://github.com/dart-lang/sdk/issues/42793.
* Removed the special handling for loading from non-nullable int fields
in AOT compilation. Instead, their treatment is unified with the
treatment of the new unboxed native fields, since the source field is
always unboxed and the result of the load is also always unboxed, as
code involving them is always optimized.
Bug: https://github.com/dart-lang/sdk/issues/40813
Change-Id: Ia02aa3e872c1fefd906fd67b55021ea1797556e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155604
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The new logic classifies the LHS and RHS of the equality check as
either null, non-nullable, or potentially nullable, and then either
promotes, treats the expression as equivalent to a boolean, or does
nothing, as appropriate.
This means, for example, that a comparison between a non-nullable
value and `null` is now known to evaluate to `true` for reachability
analysis.
Note: as part of this change, it was tempting to trigger promotion
whenever a varialbe is equality compared to an expression of type
`Null`, but this would be unsound (consider `(int? x) => x == (x =
null) ? true : x.isEven`). So we still only promote when the variable
is compared to a literal `null`.
Fixes#41985.
There's a corresponding spec change out for review:
https://github.com/dart-lang/language/pull/1134
Change-Id: Id7f1d4eaa3b0fa57124445bb8352eef32c304feb
Bug: https://github.com/dart-lang/sdk/issues/41985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155926
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If a static error test contains "[web]" error markers, this runs them
on DDC and dart2js, parses the output, and tests that the compilers
report the expected errors.
Change-Id: I8b846f75828a0078f61c2fc1f3da0a4a587349cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158100
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
External fields whose type is non-nullable don't need to be
initialized (in fact they can't be initialized), so we shouldn't
report "uninitialized field" errors for them.
This CL also adds some basic tests of the functionality of external
fields, making sure that the getters and setters they introduce are
properly resolved and that their types are properly respected by
inheritance checks.
Change-Id: I9b08727ab0d45d24801af3721e332c7ec21d08bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I would have prefered to have renamed them all to undefined_super_member,
but that would have broken existing links. Some day we should add the
support necessary to allow for forwarding so that we can rename codes.
Change-Id: I81e416407e3464b5b60a4dbbfe60a375eb47bb84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157921
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a reland of a528b19d2c
Updating the hash of the empty type argument vector in write-protected memory caused a crash in precomp mode.
The fix is to correctly initialize the hash so it does not need an update.
Original change's description:
> [VM/runtime] Fix computation of the hash of recursive types.
>
> When computing the hash of a type, only include the hashes of the type arguments corresponding to the type parameters of the type's class and not of the whole type argument vector, otherwise, the variable location of TypeRefs in the base class type arguments may result in different hashes.
>
> Add a regression test (this test was not failing in all configurations, since the issue becomes visible depending on the order in which types are loaded and finalized).
>
> This fixes issue https://github.com/dart-lang/sdk/issues/42954
>
> Small improvement: pick hash value 1 for a vector of dynamic types, so it can be cached and not recomputed repeatedly, which was the case with value 0.
>
> Change-Id: I3468952cbf61944a82cf8e00efbf4952bd831fbe
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157563
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Régis Crelier <regis@google.com>
Change-Id: I538b4538c69472e09b7bd745c6bd41023e1f154f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157781
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
sgrekhov