Previously, when initializing from dill, if the dill we initialize from
has a macro in it (and we don't remove it because of invalidation) the
macro system would think it was a precompiled dill and thus not compile
it as something it could use for running macros. Then when it tried
to use it, it would figure out it didn't have it (and crash).
This CL fixes the issue by reworking the logic:
* Assume the platform is there (dart: uris)
* Assume the uris given specifically as precompiled (and not removed
because of invalidation in/by the incremental compiler) is there.
No tests are added, but it has been manually tested in flutter.
Change-Id: Ica6c4f2f0601334d50beccdd7cf9d5740e611384
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239026
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL implements `NativeFinalizer` in the GC.
`FinalizerEntry`s are extended to track `external_size` and in which
`Heap::Space` the finalizable value is.
On attaching a native finalizer, the external size is added to the
relevant heap. When the finalizable value is promoted from new to old
space, the external size is promoted as well. And when a native
finalizer is run or is detached, the external size is removed from the
relevant heap again.
In contrast to Dart `Finalizer`s, `NativeFinalizer`s are run on isolate
shutdown.
When the `NativeFinalizer`s themselves are collected, the finalizers are
not run. Users should stick the native finalizer in a global variable to
ensure finalization. We will revisit this design when we add send and
exit support, because there is a design space to explore what to do in
that case. This current solution promises the least to users.
In this implementation native finalizers have a Dart entry to clean up
the entries from the `all_entries` field of the finalizer. We should
consider using another data structure that avoids the need for this Dart
entry. See the TODO left in the code.
Bug: https://github.com/dart-lang/sdk/issues/47777
TEST=runtime/tests/vm/dart(_2)/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
TEST=tests/ffi(_2)/vmspecific_native_finalizer_*
Change-Id: I8f594c80c3c344ad83e1f2de10de028eb8456121
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-ffi-android-debug-arm64c-try,dart-sdk-mac-arm64-try,vm-kernel-mac-release-arm64-try,pkg-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-nnbd-win-release-ia32-try,vm-ffi-android-debug-arm-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,benchmark-linux-try,flutter-frontend-try,pkg-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The order of operations for type inference of a generic invocation is
now:
1. Create some constraints on type parameters by trying to match the
return type of the invocation target as a subtype of the incoming
type context. (For a constructor invocation, the return type of
the invocation target is considered the raw uninstantiated type of
the class enclosing the constructor declaration.)
2. Downwards inference: partially solve the set of type constraints
accumulated in step 1, to produce a preliminary mapping of type
parameters to type schemas.
3. Recursively infer all arguments to the invocation, except that if
experimental feature `inference-update-1` is enabled, skip any
arguments that are function literals (a.k.a. "closures"). Obtain
the type contexts for the recursive inference by substituting the
preliminary mapping (from step 2) into the corresponding parameter
types of the invocation target. For each argument that is
recursively inferred, create additional constraints on type
parameters using the resulting static type.
4. If no arguments were skipped during step 3, go to step 7 (this
always happens if `inference-update-1` is disabled).
5. Horizontal inference: partially solve the set of type constraints
accumulated so far, to produce an updated preliminary mapping of
type parameters to type schemas.
6. Recursively infer all of the invocation arguments that were
previously skipped. As in step 3, obtain the type contexts for the
recursive inference by substituting the preliminary mapping (this
time from step 5) into the corresponding parameter types of the
invocation target. Again, for each argument that is recursively
inferred, create additional constraints on type parameters using
the resulting static type.
7. Upwards inference: solve the set of type constraints accumulated so
far, to produce a final mapping of type parameters to types. Check
that each type is a subtype of the bound of its corresponding type
parameter.
8. Check that the static type of each argument is assignable to the
type obtained by substituting the final mapping (from step 7) into
the corresponding parameter type of the invocation target.
9. Finally, obtain the static type of the invocation by substituting
the final mapping (from step 7) into the return type of the
invocation target.
This addresses simpler cases of
https://github.com/dart-lang/language/issues/731. Note that if
experimental flag `inference-update-1` is disabled, the behavior is
unchanged.
Note that steps 2 and 5 use the same algorithm as each other (they
only differ in how many type constraints have been accumulated so
far), so I've renamed the function that performs it from
`downwardsInfer` to `partialInfer`.
Change-Id: I10d3288d4f4ba9e2b6bc18409186ddc67ca2ee9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238881
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The test harness wasn't waiting on `CliAppFixture.onAppStarted` which
could cause an unhandled exception if the test cleanup started before
the target application finished initializing. This typically only
occurred while the test was running on a machine under load.
Fixes https://github.com/dart-lang/sdk/issues/48669
TEST=Locally while running under load (e.g., `stress -c 72`)
Change-Id: Ieb67e46f62c33101490899440574fb57fc0f8882
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238922
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
In order to address https://github.com/dart-lang/language/issues/731
(improved type inference for `fold` etc.) we're going to need to
sometimes defer analysis of invocation arguments that are closures, so
that closure parameters can have their types inferred based on other
parameters. To avoid annoying the user with inconsistent behaviors,
we defer analysis of closures in all circumstances, even if it's not
necessary to do so for type inference purposes.
This has a minor user-visible effect: if an invocation contains some
closures and some non-closures, any demotions that happen due to write
captures in the closures are postponed until the end of the
invocation; this means that the write-captured variables remain
promoted for other invocation arguments, even if those arguments
appear after the closure. This is safe because there is no way for
the closure to be called until after all of the other invocation
arguments are evaluated. See the language tests in this CL for
details.
Note that this change only has an effect when the experimental feature
`inference-update-1` is enabled.
Change-Id: I283fc5eb07af2aeca0a06d523011d8c4617fbad7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237720
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows us to avoid some redundant computation (we don't have to
match up arguments to the corresponding parameters twice). It also
paves the way for supporting improved type inference of `fold`
(https://github.com/dart-lang/language/issues/731) because it will
allow us to resolve some arguments (gathering more constraints), then
compute a new set of inferred types, then resolve more arguments, and
so on, rather than forcing us to do all the constraint gathering at
the end.
Change-Id: I67d8b8228390ced14281145a4614f66c8e3c7e73
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the process, I removed 'useFastaParser' from both the public API and
the implementation class. I also removed 'enableTiming' from the public
API.
The other getters were left because they seem like reasonable options
for plugins to want to query. If you disagree, we can address them in a
future CL.
Change-Id: Ia5630b71190dd68bcd66199baa0c05846fcc37b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238661
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Rename DataSource -> DataSourceReader and SourceReader -> DataSource to more accurately reflect these classes' new roles. 'Writer' and 'Reader' are used for the higher level class that composes serialization operations. The 'Sink' and 'Source' handle the low-level conversions to/from the storage format.
Change-Id: I384b5f134beb040676f8e1ef4fba056e0c40358f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238243
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Copy comments from original interfaces to new DataSink and DataSource and organize methods based on original interface.
Note: If the reorganization makes the diff on this too complicated I can just add the comments and leave in the order it was in.
Change-Id: I959ae19d80ad330ef67334effb8aad8661689937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238242
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Move DataSource/DataSink to implement serialization via composition rather than inheritance taking simple interfaces that do low-level writes/reads.
Note: Names and locations of classes will change throughout the next several CLs.
Change-Id: I04807d64a1238b42308ec93e5b5dda6ef2101c00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238241
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Combine AbstractData(Source/Sink) and Data(Source/Sink) into a single class. This simplifies the inheritance hierarchy before switching to a composition structure.
Note: Names of classes will change throughout the next several CLs and comments from the interface get added back in here:
https://dart-review.googlesource.com/c/sdk/+/238242
Change-Id: I50597e04f5b18a1150da4822c4886d12896bed8f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238240
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Copy mixin logic into AbstractSink/AbstractSource classes since these are the only usages of the mixins.
Note: Names and locations of classes will change throughout the next several CLs.
Change-Id: Ie154741a83c3488a098f3ebf5cf340f19a1a9c52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238220
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
We don't need to call this method from
`InvocationInferrer.resolveInvocation`, because resolution of a call
to `identical` always uses the derived class
`MethodInvocationInferrer`, which inherits proper handling of
`identicalInfo` from `FullInvocationInferrer.FullInvocationInferrer`.
Change-Id: Ic511befee498bd241d2d33240b4b388a0ed74be4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238601
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Rather than compute a preliminary `invokeType` prior to calling
`_visitArguments`, we just compute the necessary substitution to go
from `rawType` to `invokeType`, and let `_visitArguments` apply it
when needed. This will improve efficiency when I add support for
better type inference of `fold` (see
https://github.com/dart-lang/language/issues/731), because it will
allow multiple passes of type inference without having to recompute
`invokeType` each time. Also, it gives `_visitArguments` access to
the `rawType`, which I will take advantage of in a follow-up CL to
make constraint generation happen at a more reasonable time.
Change-Id: I2ecabac10c0ec91fc994b4cf2d8f33a5b532a99e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238600
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
`_visitArguments` handles walking through the argument list,
recursively performing type inference on each argument.
`_recordIdenticalInfo` handles the necessary integration with flow
analysis to support type promotion via `identical(variable, null)`
tests.
We no longer call `super.resolveInvocation` from the overriden method
`FullInvocationInferrer.resolveInvocation`, but instead call
`_visitArguments` and `recordIdenticalInfo` directly.
This is part of a larger arc of work to enable better type inference
of `fold` and similar methods (see
https://github.com/dart-lang/language/issues/731). It will allow me
to add some additional parameters to `_visitArguments` that relate to
type inference, without complicating the API of `resolveInvocation`.
Change-Id: I6d8ac1af4cfbadf86d5fbfd4ba1b4652707ecfdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238505
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Johnni Winther