Instead of possibly looping over the closure function parameter names
array multiple times, just do it once. Check each entry against the
provided argument names. If none match, check the required bit (if in
null-safe mode). Also keep a count of matched names to check that all
provided names matched after the iteration.
Now that optional name checking is part of the fragment built by
BuildClosureCallArgumentsValidCheck, that method builds checks for
exactly the same things as its namesake in Function.
Also refactor the variables used by the checker into read/write ones
that need to be allocated in the parsed function and read-only ones
that can just be temporaries since no Phi nodes are needed.
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try
Bug: https://github.com/dart-lang/sdk/issues/40813
Change-Id: I3cb421dd538629d7f5499f3bbf0653d34b850dce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160725
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This CL also adds fileUri/charOffset to all TypeBuilder's and renames
Void/FutureOr/Never/Dynamic/BuiltInTypeBuilder to *TypeDeclarationBuilder
so match their relation to TypeBuilder/TypeDeclarationBuilder.
Closes#42962
Change-Id: Iee5102134574d24f748103282a37bb9a85a0ac2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161165
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@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>
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>
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>
Add a test where a class that has no generative constructors
declares an instance variable which is final and has no initializing
expression. With https://github.com/dart-lang/language/pull/1130 this
is an error, and that error is expected by the test. Also test that
it is not an error to have an uninitialized final variable which is
abstract or external.
Change-Id: I6c4a46393f46587448612bd91fb99fa65f89704c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157490
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This reverts commit a528b19d2c.
Reason for revert: Failures in precompiled mode.
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>
TBR=rmacnak@google.com,alexmarkov@google.com,asiva@google.com,regis@google.com
Change-Id: I904e7043fa175d03bb9af56a9346b097b883c7a0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157700
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
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>
When converting InstanceCall to LoadField don't adjust deoptimization
environment because when we deoptimize from LoadField back to
InstanceCall we would expect to have receiver on the stack.
This is a different situation from LoadField to LoadField lazy
deoptimization in which case receiver should not be on the stack.
Regression test provided by Ryan.
Fixed: 42900
Change-Id: I6041ff02abf22a2bae0fdcd65d5b49ef8aec6204
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157182
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Konstantin Shcheglov