The key can only be an Expression but was unneedingly wrapped in
a ConstantPattern. Since the shared type analysis only handles
map pattern keys as expressions, the expected properties of
ConstantPattern were not set. Amongst these were the static type
of the key expression, which is know passed directly to the
handleMapPatternEntry method.
Change-Id: I705fc655e440d534ccc442c9c1359c377955b3b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288282
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
These AST nodes were so far internal to the CFE, but since we need to
move the pattern lowering to the constant evaluator we need to support them in the AST defined in package:kernel.
TEST=existing
Change-Id: Ie6c5f0f8ad75a866c5d965fdf506bc869ffaf654
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288241
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This adds an [isSynthesized] flag to the [VariableDeclaration] the
signal when the variable doesn't correspond to a variable in the
source code.
The name of a variable can only be `null` if it is synthesized.
Partially in response to
https://github.com/dart-lang/sdk/issues/51554
TEST=existing
Change-Id: I94591971f11da09d210c8b25a2d05e22ca05dc62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286961
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This allows us to better track all kinds of accesses to record
implementation classes in dart2wasm, which generates separate
record implementation class per record shape.
This change also allows us to remove mutable dispatch targets
which were used to implement dynamic accesses to record fields,
and make tracking of record field types more accurate
(record fields are now versioned per shape).
This is also a step towards inferring actual record types.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/records.dart
TEST=pkg/vm/testcases/transformations/type_flow/transformer/records_dart2wasm.dart
TEST=language/records/simple/dynamic_field_access_test
Issue https://github.com/dart-lang/sdk/issues/49719
Fixes https://github.com/dart-lang/sdk/issues/51363
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try
Change-Id: Icba62a7ca8cfd8ddbc7f2b7c38aeabbef5caec4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286950
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This propagates information about reported error to the caller of
a shared type analysis. This is used to properly turn errors into
invalid expressions/patterns, as is normally done in the CFE in
face of errors.
Change-Id: Ibb8adedccb8314fabfe18ecaa3559e32ad7267ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286145
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This adds support for generic types in exhaustiveness checking.
There are two main obstacles:
1) Types that are not Dart subtypes might be related in the context
of exhaustiveness. For instance
sealed class A<X> {}
class B extends A<num> {}
method<T>(A<T> a) {
switch (a) {
case B(): ...
}
}
Here B is not a Dart subtype of A<T> but must still be a subtype
in the context of exhaustiveness since T could be num at runtime.
2) It is non-trivial to compute the subtypes of a generic sealed class
that is both sound and precise enough to be useful. For instance
sealed class A<X> {}
class B extends A<num> {}
class C<X> extends A<X> {}
class D<X extends num> extends A<X> {}
class E<X extends E<X>> extends A<X> {}
Computing the subtypes of A<F> for some type F, we would like to
exclude B (assuming F is not a supertype of num) because it
cannot be inhabit A<F>, and include C<F> so that we recognize
that C<F> exactly covers all C instances of A<F>. We would also
like to include D<F> but if we don't include the added `extends
num` bound, we might conclude that D<num> is _not_ sufficient to
cover D<F>. And what to do about E, can we even come up with a
type that represents the valid values?
The solution is threefold:
1) We add an 'overapproximate' function of types, which
replaces all type variables with their default types. This will compute
A<dynamic> for A<T>, A<int> for A<int>, A<List<dynamic>> for A<List<T>>,
and E<dynamic> for E<T extends E<T>>. This is similar to instantiate-
to-bounds, but is recursive.
We use this to test whether a type without type variables is a potential
subtype. For instance testing B <: overapproximate(A<F>) = A<F> shows
that B _cannot_ be a subtype of A<F>, and testing
B <: overapproximate(A<T>) = A<dynamic> shows that B _can_ be a subtype
of A<T>.
2) For finding subtypes of a sealed type, we recognize the case
when a type is a trivial subtype in which all type variables are passed
directly to the superclass, for instance like C<T> in the example. For
other cases we overapproximate the this type of the subclass.
3) To ensure that the [StaticType] can be subtype in the normal Dart
sense but also handle the overapproximation when computing sealed
subtypes, a new [WrappedStaticType] is added. This bridges the subtype
relation such that for instance B, when created as a sealed subtype
of A<T>, is both a subtype of A<num> (as it normally is) and of A<T>,
which it is by construction.
Change-Id: I9970c46009938ef15625e1193faf916b7544ce0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284681
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This replaces the [Library] parameter from bounds checks and
type inference methods with a `isNonNullableByDefault` parameter,
enabling usage of these algorithms in library-agnostic code, like
features only available post-nnbd.
Change-Id: Id565d00e1c20d25e7e3388badbb2d7f11c015802
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284642
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
with a distinction between `inlineClassMember` and `extensionMember`.
Fixes#51338
Change-Id: I169c285537754137d5b32effc9697c2b9f4eb5c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283864
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Before this CL kernel tags had specialized tags that was marked by the
single high bit, then using the three lowest bits for a value:
128 + value = 0b10000xxx
136 + value = 0b10001xxx
144 + value = 0b10010xxx
So the numbers from 128 to 151 is taken by this scheme, but because of
the high bit marking stuff being special we can't really use 152-256.
This CL shifts the specialized tags up so it instead uses the 3 highest
bits as a marker while still using the lower 3 bits for the value:
224 + value = 0b11100xxx
232 + value = 0b11101xxx
240 + value = 0b11110xxx
This takes up 224-247 and leave 248-255 unused. It would let us use
128-223 though.
(If we eventually need more we can probably remove one of the
specialized ranges (SpecializedVariableSet isn't used very much in
previously sampled dill files) and use 4 bits for tagging).
Additionally, a tool to print free tags has been added (via binary.md),
and the "binary version is in sync with VM" test has been prepared
for version > 99.
TEST=Existing tests.
Change-Id: If77b12cee6fc3801628dd67dc40afbb018ec8a61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284302
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This makes it easier to navigate around in editors that can go to
matching braces/parenthesis (e.g. jump from end of constant section to
start).
TEST=Fixes kernel text printer & updates tests.
Change-Id: I6cbf34f5a62e11454e5de4d5fc9a313e0c6cf36c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283641
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This adds support for record types in the exhaustiveness algorithm.
The original algorithm was based on that record pattern would
match fields on all types, but that is no longer the case. Instead
record patterns only match corresponding to their own type. For this
reason the testing code is updated to create record spaces in relation
to a type. For instance, when the test create a record space {x: B}, it
is know create in relation to a type, say (x: A, y: A), and the create
space will therefore have (x: *, y: *) structure where the y: component
is implicitly Top, similar to how object patterns are used.
Unlike the Dart record types used for type checking and inference, the
record types used for exhaustiveness do not take the field types into
account for its subtype relation. This is avoid conclusions like
(int i, Object o) and (Object o, int i) having no values in common because
their corresponding types (int, Object) and (Object, int) are not subtypes
of each other. Instead, the subtype relation for record types used for
exhaustiveness only use the structure of the record to determine whether
two types are related.
Note though, that fields of a record type still know the type of the field.
This is used when expanded a record type into a space; the field spaces
will be derived from the field types in this case.
Change-Id: I84735d827494bcf384fd5f419d71933830ff5d15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283182
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
* Add an `targetOS` argument to `pkg/vm`'s `compileToKernel`,
that contains the target operating system's name.
* Add a new `--target-os` command line argument for all binaries
that use `compileToKernel` for clients to provide the target
operating system, if known.
* Add a new`"vm:platform:const"` annotation to certain field and
getters in the Platform class.
This annotation is used to annotate static getters and fields with
initializers where the getter body or field initializer must evaluate
to a constant value if the target operating system is known. This
annotation may be used outside the Platform class and in user code.
For example, this annotation can be used on a static `String` field
that is initialized with one value if `Platform.isWindows` is true
and to a different value if `Platform.isWindows` is false.
Note: If the const functions experimental flag is disabled, then
any annotated static methods can only contain a single expression
whose value is returned. If it is enabled, then the static method
is evaluated as if it is a const function with the special
handling of annotated static fields and getters above.
* Create a VM constant evaluator that evaluates uses of static getters
and fields marked with the above annotations when a target operating
system is provided.
* Use the new VM constant evaluator in the unreachable code elimination
transformer.
TEST=pkg/vm/test/transformations/platform_use_transformer
pkg/vm/test/transformations/unreachable_code_elimination
Change-Id: Ie381de70486a767fd7b1d515fd9e6bb58c6bf090
Bug: https://github.com/dart-lang/sdk/issues/31969
Cq-Include-Trybots: luci.dart.try:pkg-linux-release-try
CoreLibraryReviewExempt: Just adding vm-specific annotations.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274386
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
There's been some talks about weird failures on DDC and there was
ideas that this was caused by some sort of leak (of kernel libraries).
I haven't really found any "meaningful" leaks that should be able
to cause that.
What I have found is this:
* a temporary leak where the vm seemingly gets "one behind".
That's fixed here by creating a class for the ddc batch compiler,
having things in field variables etc. It shouldn't influence results.
* a leaks via https://github.com/dart-lang/sdk/issues/51317 --- but
that's just wasted memory, I can't see how that should influence
results.
* a leak via kernels dummy nodes --- again it shouldn't influence
results (unless we're leaving dummy nodes in the output somewhere
--- which, considering I'm removing that in my test by null'ing out
the parent pointer and stuff still working I'm guessing we're not).
* another leak via some ports map after a crash, but that seems
to go away on its own (the VM cleaning it up later than I think it
should?). Again it shouldn't influence anything other than
(temporary) wasted space.
I've wired up the leak testing stuff into the DDC batch mode so that
one can go into "leak test mode" by doing `export DDC_LEAK_TEST="true"`
on the terminal (I think `set DDC_LEAK_TEST="true"` on Windows).
Then one could run test.py, say
```
python3 tools/test.py -t10000 -c dartdevk --nnbd weak -m release \
-r none --enable-asserts --no-use-sdk -j 1 co19/LanguageFeatures/
```
and attach the leak tester via
```
out/ReleaseX64/dart \
pkg/front_end/test/vm_service_for_leak_detection.dart --dart-leak-test
```
Currently this finds - if I recall correctly - 3 leaks (I think all via
the ports map stuff), but it all goes away again on it's own, so likely
another case of the VM somehow getting "one behind".
Change-Id: Idbf057e3aedfe7b256370f90ddf72f1f8e6798a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282027
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This flag is no longer used by the front-end and can be removed.
TEST=ci
Change-Id: Ia19e9927d48d4ae486ee7ffa110abb9960a0840d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281461
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
TargetFlags.enableNullSafety is set to true by default and
also renamed to TargetFlags.soundNullSafety to better reflect its
meaning.
TEST=ci
Change-Id: I2c2f30c2af6502fd9a96141dc60e4afbf8c524fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280216
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Fixes#51095
TEST=ci
CoreLibraryReviewExempt: There are no API changes, just removal of superfluous words in the comments.
Change-Id: Ib1020c62fe6baed5ca68f0074323f025cc90e9f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279500
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
An update for co19 is available at https://github.com/dart-lang/co19/pull/1759
TEST=Existing tests run after change, two new tests for edge cases.
Change-Id: I408e398d532ba2c2e8e60777bb4f7bd0057e27fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278912
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Closes https://github.com/dart-lang/sdk/pull/50860
GitOrigin-RevId: b27066c37f93c8c6d1123d6ebd6a4c0afcf59844
Change-Id: I15fa4aea1dad45daf168e34d1c4450320ec9b40a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277742
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This adds support for having a final field and an external constructor
without error, assuming that the external constructor initializes the
final field. This supports the inline class with external members use
case.
Change-Id: I33b78275e967636ed0697d17f7921e9eee30401b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279095
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This reverts commit c70d266270.
Reason for revert: Crash detected
Original change's description:
> [cfe] Support external constructor with final fields
>
> This adds support for having a final field and an external constructor
> without error, assuming that the external constructor initializes the
> final field. This supports the inline class with external members use
> case.
>
> Change-Id: Ie297ccc39b0a0731c146f9ac0698bba3fd83bfeb
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278502
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Commit-Queue: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I339d9008cb84cda8dc20f29d1e103289bb5596b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278820
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Auto-Submit: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This adds support for having a final field and an external constructor
without error, assuming that the external constructor initializes the
final field. This supports the inline class with external members use
case.
Change-Id: Ie297ccc39b0a0731c146f9ac0698bba3fd83bfeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278502
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
Additionally, make class flags a uint because there are now more than 8 flags.
TEST=pkg/front_end/testcases/mixin_class/*
Change-Id: I4fe7babfa9911df0821cc73528e6b10b2ea3b92d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275402
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This enables the front end to skip the old-style (enum-based)
exhaustiveness checking algorithm when pattern support is enabled,
because with pattern support enabled, switches on enums are required
to be exhaustive (this will be checked by the new exhaustiveness
checking algorithm).
That in turn means that in the future, when we remove support for
language versions that lack patterns support, we will be able to
remove the old-style exhaustiveness checking algorithm.
This change has a small effect on code generated by the WASM back-end
(the only back-end that uses `isExplicitlyExhaustive`): for a switch
statement that is exhaustive *and* has an unreachable `default`
clause, after testing all the cases, the WASM back-end will generate a
branch to the `default` case. Previously it would instead generate an
`unreachable` instruction. There should be no behavioural difference
because the instruction in question is unreachable in both cases.
Also, there should be negligible code size difference because the body
of the `default` case is being emitted either way.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Id6bd7d9a540cb1b4d9c3624db8ff494438276bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274924
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
- Flip flag to make strong null safety the default
- Remove code that auto detects null safety mode from source files,
it is necessary to specify --no-strong-null-safety to opt out.
- Retains sniffing of AOT/JIT snapshots and kernel files to determine
null safety mode, the opt out has to be done when generating these
file.
TEST=ci
Change-Id: If2c9608eedb7c46d9c3cd85e261ee9640e0d28eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261140
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Validates a yaml format encoding a native asset mapping, and
synthesizes a component containing a pragma with this information.
Yaml example:
```
format-version: [1,0,0]
native-assets:
linux_x64:
'package:foo/foo.dart': ['absolute', '/path/to/libfoo.so']
```
Generated format example:
```
@pragma('vm:ffi:native-assets': {
'linux_x64' : {
'package:foo/foo.dart': ['absolute', '/path/to/libfoo.so']
}
})
library;
```
TEST=pkg/vm/test/native_assets/synthesizer_test.dart
TEST=pkg/vm/test/native_assets/validator_test.dart
In a follow-up CL, we will consume the yaml from `gen_kernel`
and consume the pragma in the VM for `@FfiNative`s.
Bug: https://github.com/dart-lang/sdk/issues/49803
Change-Id: Ie8d93b38ff4406ef7485e5513807e89b2772164b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/272660
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
