So far this just builds the wasmer library, copies it into the sdk
directory, loads the library, and allows you to compile WASM modules.
You can't actually do anything with the modules yet.
Bug: https://github.com/dart-lang/sdk/issues/37882
Change-Id: I7d7cfe5721bbe38a6afe76f326518e714d236ed4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158367
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This code was inadvertently falling through to the `throw` if `VoidType`
was encountered (although this case currently never happens). In
addition, we were missing cases for some of the newer `DartType`s.
This CL fixes those cases and removes Object from the classes implied by
`DynamicType`.
Change-Id: Ibfecd92c0113d11eb8870d511d60cbc34ac1bfa0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159020
Commit-Queue: Mayank Patke <fishythefish@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The refresh was causing "Cycle loading state error", so it is possible
that this CL will fix this long standing issue.
Bug: https://github.com/dart-lang/sdk/issues/43073
Change-Id: Id1eeacd01cf10e918b002d227c8942e38bed543c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This code worked around bugs in how TypeMasks were generated 4+ years
ago. Now subtype cones are generated from the least upper bound of
instantiated subtypes, resulting in TypeMasks that are no longer
disjoint for 'double' and 'int'.
Change-Id: I7189c4447f2c41db7abb7a0ea1240eca6e28aa7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159000
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
When reading a secondary snapshot, re-run the dispatch table initialization found in the root snapshot. Since each loading unit's contribution to the dispatch table is scattered, it would take more snapshot size to try to serialize their contributions separately. We'll revisit this when we can defer Class, Function and Code, which will prevent the root snapshot from referencing all Codes.
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Iefd2b98647b96ae59a7efe92897538f5cf8c2426
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158923
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
fields.
This brings it more in line with the lib_2 version.
Change-Id: I99e4f6a467fa5b58d6e7c5206e1f6d9956fc60bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158961
Auto-Submit: Mayank Patke <fishythefish@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
I see no reason why this would be useful.
But it might be harmful.
When we create file1 that imports file2, and call getFileSync(file1),
the analyzer will read both file1 and file2 while building the
file graph. So, when we then create file2, it will not be read unless
we call changeFile(file2). And we don't.
Actually, if we want to simulate how migration works, we should first
create all files, and then migrate them.
R=paulberry@google.com
Change-Id: I22ff994d346c4ad985e5d06a34e9fd854d451757
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously, we were creating nullable typemasks and then stripping off
the nullability if non-nullability was specified. We should be assuming
non-nullability as the default and adding nullability in if required.
The former approach has the issue that typemasks for `Null` keep getting
converted to empty typemasks when we try and remove the nullability.
Change-Id: I58907c1c45c756f023d67043ce88eb82c4b1589c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158371
Reviewed-by: Stephen Adams <sra@google.com>
When `--null-assertions` is enabled, values returned from @Native
methods and getters with non-nullable return types are checked.
Change-Id: I4b38e651a9a6b370ebed5420a3cfac0a53cfeb60
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158527
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
The new rules for null-safe number promotion apply to both operators
and ordinary method calls, so I'll be implementing them in terms of
MethodElement.name rather than an operator TokenType. To make this
possible, we need to pass the method element to
TypeSystem.refineBinaryExpressionType.
I'm doing this as a separate CL from the main implementation so that I
can verify that it doesn't introduce backward compatibility issues.
Bug: https://github.com/dart-lang/sdk/issues/42629
Change-Id: I6be9086553ee0ea9994994c903880fe9bb4477fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158480
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This also highlighted a couple of mistakes in the patch files for
dart:_internal and the test.
Change-Id: I60b4e7d5673d64f85a95108c9e03f9328249b9d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153021
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Specifically this allows passing the result of `someUri.toFilePath()` on windows as a multi-root.
These paths have drive letters which are not understood by `Uri.base.resolve`.
Change-Id: I66d452be1e1c6923e61c1843bdfbce83a7c12f94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158900
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Jake Macdonald <jakemac@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>
Before this CL the textual outline didn't know about imports and exports
and thus couldn't sort them.
This CL makes it know about them and allows imports and exports to be
sorted internally, but not mix with other stuff (e.g. imports should be
placed after "foo() {}" just because "f" comes before "i", but putting
"import 'a.dart'" before "import 'b.dart'" is OK.
This CL does not sort the hide and show entries.
Change-Id: Ic640cdaa98ac3562f8b36b21180a26584cb6d205
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158551
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Before this CL the textual outline didn't know about named mixin
applications which caused it to insert "fences", i.e. splaces it
wouldn't sort across.
So for instance
class E {}
class D {}
class C<T> = Object with A<Function(T)>;
class B {}
class A {}
would not be sorted fully because class C is a named mixin application,
something it didn't know about, and it would only allow stuff on either
side to be sorted. So the sorted output would have been
class D {}
class E {}
class C<T> = Object with A<Function(T)>;
class A {}
class B {}
With this change it knows about it and the output would now thus be
class A {}
class B {}
class C<T> = Object with A<Function(T)>;
class D {}
class E {}
Change-Id: I97b28706732582d0c37f1b2c052b9f6eaf862a5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158550
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. before this change an empty class output would have been
class Foo {
}
now instead it becomes
class Foo {}
this matches what the formatter does.
Change-Id: Id08edc5259bae00deff9a66b4ae745f21c192358
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158549
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. before this change a procedure output would have been
foo() { }
now instead it becomes
foo() {}
this matches what the formatter does.
Change-Id: Ieb538d61e527cbec26d1d65ed6de349311dd0163
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158548
Reviewed-by: Johnni Winther <johnniwinther@google.com>
We will need this also to implement '16.35 Lexical Lookup' from the spec.
Change-Id: I3b77c4a016fd54771b07957d522074aeb8dd1938
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158802
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Also updates for tests when the left side is a SimpleIdentifier.
Change-Id: I8da1392e2aa8e11a323e09aa380fb49e8cbf38da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158522
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Just getters for now, not field, and not migrating existing getters
to them.
Change-Id: Id93c5988c606c45d0833aa7b3fbfefa507cbdb2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158525
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, BinaryExpressionResolutionTest contained a bunch of useful
tests that should pass in both legacy and null-safety modes, but they
were only run in legacy mode (and a very small set of tests were run
in null-safety mode). This CL moves those tests to a mixin so that
they get run in both modes.
This is necessary because in follow-up CLs I will be changing the type
analysis rules for binary expressions in null safety mode (in
accordance with
https://github.com/dart-lang/language/blob/master/accepted/future-releases/nnbd/number-operation-typing.md),
and I want to make sure not to lose test coverage.
Bug: https://github.com/dart-lang/sdk/issues/42629
Change-Id: I3eac5fd563d7505abe2930835b14867bebec3512
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158482
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds a debugger mechanism to replace part of
--causal-async-stack's _asyncStackTraceHelper runtime entry.
It recognises async and async* functions and adds a synthetic
breakpoint on entry into the wrapped async_op, making sure we
don't get "synthetic" frames as we're stepping in and out of
the async code.
Change-Id: I1df6e6874de2fa9185f27a1a8873ad0071ad9fb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157480
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@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>
