This adds the `recordTypeWith` method to `TypeProvider`, a method
instantiating a record with provided positional and named fields.
By instantiating specific record types, we can match user-defined types
against specific record structures, for instance to validate that a
user-defined type is compatible to a certain record. For me, this would
be a helpful addition to the analyzer's public API.
Change-Id: I52e70eb0cbb0a0edf919b7b0f8901e6de1e00a64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277401
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* Don't compile it with omit frame pointer even in PRODUCT.
* Dump the first frame even if we give up on unwinding.
* Dump compiler state even if we give up on unwinding.
* Don't abort stack dump if PC for the outermost frame is 0 (can happen
when calling pure virtual method for example).
TEST=manually tested by making compiler crash during code generation
Change-Id: Iddeafbdad8e8588f19197d5dd49af14b8fc63134
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278341
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This separates setter, getter, and method forwarder types. Setter
forwarders now only take a receiver and a value arguments. Getter
forwarders take only a receiver argument. Method forwarders are the same
as before: a receiver, lists for type, positional, and named arguments.
This is mainly to allow passing more arguments to the method forwarders
without having to pass dummy values when calling getter and setter
forwarders. For example, the vtable entry to fix#50661.
This also fixes return values of field sets (when there is no setter).
New passing tests:
- language/getter/setter_interceptor_test
- language/if_null/assignment_behavior_runtime_18_test
- language/if_null/assignment_behavior_runtime_20_test
- language/if_null/assignment_behavior_runtime_25_test
- language/optimize/setter_test
Change-Id: I17381fba04f089b974d6c435e4c38dc90b7e5527
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277986
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This change fixes CompileType::CanBeFuture() which previously attempted
to use Class objects by class id without first checking if cid is internal.
Cid can be internal (SentinelCid) when CompileType::CanBeFuture() is
called for a return value of an async function when it is returning
a value of an uninitialized late local variable (such Return
instruction is unreachable).
TEST=runtime/tests/vm/dart/regress_flutter117892_test.dart
Fixes https://github.com/flutter/flutter/issues/117892
Change-Id: I63f0ca32d6246487f5c33d983cef9bd22aaa2fb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278094
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The representation field of an inline class is not part of the
generated code - it does not have a corresponding synthesized top-level
methods like the other inline class members. Therefore, to support
access to the representation field, a new `representationName` field
is added to `InlineClass` that holds the name by which the
representation field can be accessed.
An access to the representation field is at runtime an access of the
receiver itself. To show that the static type of the expression changes
from the inline type of the receiver to the declared representation
type, an `AsExpression` is inserted. Since this check is not needed
at runtime, this node is marked with the new `isUnchecked` flag, that
backends can use to skip the check.
TEST=pkg/front_end/testcases/inline_class/field_access.dart
Change-Id: I635af414af2ddc541352078766ce57a9d8ded601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277983
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This push the constant context for constant patterns such that
the constness is propagated to subexpressions.
Closes#50629
Change-Id: Idcb279765c5464ba17abb98b3f9eb852a7c87b96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277860
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Our AOT compiler may make optional parameters mandatory (e.g. if all
call-sites pass the parameter). Doing so removes the need for the
[VariableDeclaration] to have an initializer, which we clear.
=> This CL also clears the has-declared-initializer flag on the
[VariableDeclaration]
This makes the text representation of AOT-transformed kernel files
less verbose by not printing `has-declared-initializer`.
TEST=ci
Change-Id: Id12cdbc2899c6e1f378a01c27ef4ec8e0ca3f328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277987
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This field was added to track the assignments in `setUp` function
in tests, so allow better `late` inference for variables that get
assigned in `setUp`. But this might be needed not only for
`EspressionChecksOrigin` but also for `DynamicAssignmentOrigin` and
`AssignmentFromAngularInjectorGetOrigin`, so I moved this field to
the base `EdgeOrigin` class.
Tested: added a test that fails without this change.
Change-Id: I9c7c6b2e8b21f94e80e505cf24f2072bd8df703a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277682
Reviewed-by: Paul Berry <paulberry@google.com>
Cascaded calls usually end up being `StatementExpression`s, and
for those dummy edges are added. But in a cascade, the result of
the expression is the same as the target, so these dummy edges
happen to affect nullability of cascade's target.
This fix just drops adding dummy edges for `StatementExpression`s
those expression is a cascade. I guess the better fix would be to
make dummy edges into suggestions, since AFAIUT, their meaning is
"it's fine to make this nullable" vs "this shouldn't be nullable"
added by the method invocation, so the latter should ideally win.
Not sure that will fit into the algorithm though.
Fixes: https://github.com/dart-lang/sdk/issues/49689
Tested: repro test now passes
Change-Id: I62b408c7307df4ea485b8a925cf4537fd9890024
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277681
Reviewed-by: Paul Berry <paulberry@google.com>
I also switched to code `Feature.class_modifiers.enableString` because
then it is easier to navigate to the feature (twice) and see if it is
release.
Change-Id: Ia730d7b22ded44472effd1d7534d2d5d5b01d275
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278220
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
