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>
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 cl applies the mixin transform only on the full dill. In addition,
this cl also adds a concatenate dills step to more closely match
modular builds in production.
Change-Id: Icb37c5e2180c9e8246334143a6f772a203f80bf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238320
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Subclasses of the _Function class are generated on the fly as fields
with function types are encountered. Therefore, this class must be early
in the initialization order.
Change-Id: Ia0b998c443af9f6bdb4af512f6da99e6e3767c1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237681
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
It had bit rotted slightly: we were not properly accounting for
variance when gathering type inference constraints from the comparison
of two interface types.
Also, some of the tests needed to be updated to account for follow-on
errors.
Change-Id: Ife9feae3e2180a179ebc8503751690789dc1483e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `regress` folder in tests/web and tests/web_2 has been renamed to
`issue`. All issue-numbered tests have been placed there; other tests
have been moved out of that folder.
Change-Id: I4534d34b2ef21f7accc45c3ce097d9be74845e4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235984
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This adds formatting support for upcoming language features:
- Named arguments anywhere
- Enhanced enums
- "super." parameters
It doesn't change the formatting of any existing code, so it should be
safe to roll this in without coordinating a pre-built SDK roll.
I also went ahead and ran the formatter on the related language tests
since before now they couldn't be formatted. (And I incidentally ran
the formatter on the other enum tests sitting in the same directory.)
Edit: Actually there is one small change to existing formatting: enum
declarations will now get a blank line inserted before them. Most hand
authored enums already have this so will be unchanged but I see a few
diffs when formatting generated code.
Change-Id: Icefd9f10bedc589312396cf0ddb8eafc418f8dbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235284
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Unfortunately we have to give up on eager initialization of many maps
and sets due to unknown dependencies and effects in the hashCode
implemenation. Eager initialization of some cases could be recovered
as they are eligible to be `const` maps and sets.
Fixed: https://github.com/dart-lang/sdk/issues/48442
Change-Id: I6500123ff9d1fe42bacb53718a4b9e4e969ebc3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233942
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Currently, we decide whether to insert an implicit `.call` tearoff on
an expression based on the type the expression is being assigned to,
whereas the spec says that we decide it based on the context type.
In most cases, these are the same type, however when assigning to a
promoted variable, the context type is the promoted type, whereas the
"type being assigned to" is the unpromoted type.
Previously, we had no language tests of this behavior; it just emerged
naturally from the way it was implemented in the CFE. This test locks
down the behavior so that we won't change it by mistake.
We may, at some future time, decide to change it on purpose though.
Discussion about this behavior is ongoing on the langauge team.
Change-Id: I82f54c8875fd3b5829c5f75a676fdaf5eea64703
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233650
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add `isMimeType` method to `UriData` class, to allow case-insensitive
checking of the MIME type.
Add `isCharset` and `isEncoding` methods to `UriData` class,
to allow case-insensitive and alternative-encoding-name aware checking
of the MIME type "charset" parameter.
Make `UriData.fromString` and `UriData.fromBytes` recognize and omit
a "text/plain" `mimeType` even if it is not all lower-case.
Be case-insensitive in a few cases where we weren't before
(like the `charset` getter not recognizing `CHARSET=utf-8`.)
Fixes#28592
TEST=corelib/data_uri_test.dart updated
BUG= http://dartbug.com/28592
Change-Id: Ia885af69d271856af7fadfe93851e07eff6ddca2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217366
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This CL makes a lot of small corrections in enhanced_enums_basic_test,
e.g., references to variables whose name is slightly different in the
declaration and at the use site.
[Edit: This CL no longer adds a new test, `enhanced_enums_error_test`
already covers all the situations tested by that new test.]
Change-Id: I9d2aabd5ab740b91463eff12a5c676136bf4ec04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233384
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The tests check that expected errors actually happen.
There might be *too many* error markers in the tests,
since it's not clear *where* an error is reported.
Is a naming conflict reported for one or both conflicting declarations?
Is a conflict reported on the class declaration or on a conflicting
declaration?
The front-ends might need to remove themselves from some of the errors,
when the error reporting strategy is decided, but they should report
at least *one* error for each problem.
Also fixed bugs in the non-error `enhanced_enum_basic_test.dart` file.
Change-Id: I673244d1d5a8803e5b49d53150a2b3ab47522c89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231950
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This CL
* Makes :async_op only have two parameters: We take advantage
of the fact that errors not only have exception != null but
also stacktrace != null.
* Makes :async_op have no optional parameters. This reduces
code size significantly.
* Removes unused parameter in _awaitHelper calls
* Wrap the then callback instead of the error callback. (needed
to make optional parameters required)
This results in 2% code savings on a big g3 app.
The size of :async_op shrinks on average by 11%
TEST=ci
Change-Id: I38d5fba4ebebc780b48dac5aa6a250d2c7952bfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233362
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-win-release-x64-try,vm-kernel-precomp-linux-release-simarm64-try
Change-Id: Iccd080591cc3dda60b5bd2ab9d8f2261445df610
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232880
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Currently, all the language tests that exercise implicit call tearoff
do so using expressions that are either instance creation expressions
(e.g. `new C()`, where `C` is a class containing a `.call` method) or
simple identifiers.
This test exercises all of the syntactic constructs which are capable
of undergoing implicit call tearoff.
This will help ensure that some upcoming analyzer changes don't break
implicit call tearoff support.
Change-Id: I3e6471a3ba22fb3e3be38f2721db549da631668a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232920
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I'm not 100% sure we have a spec for precisely when we do implicit
call tearoffs and when we don't, but the CFE and analyzer agree on
this behavior, and I'm about to reorganize some of the analyzer code
that handles it, so I'd like to be sure the behavior is tested.
Change-Id: I1afee375181fde7b3a304aa8b71b23a45a337be0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232784
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The bad codegen reported in #48383 was due to an unused phi confusing
the expression-tree construction algorithm. It was trying to generate
data = cond ? callWithSideEffects() : null;
but `data` is unused, so somehow we generated only
cond;
We should not have unused phis at this point so I put a safety check
in the above code to not try to build an unused conditional, and
changed the dead-code eliminator to eliminate dead phis.
Now we get
if (cond)
callWithSideEffects();
I compared the output for some large apps and there were about a dozen
changes. All looked like improvements, e.g. not assigning to an unused
variable. There was some code missing that is now present, but luckily
for the large apps, it was all code that did not have real-world side
effects.
Fixed: 48383
Change-Id: Id7b32cfa0cbfb47a4d9eff174ad9ae52da99f6a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232781
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Right now the implementation of `Isolate.spawnUri(<uri>, ...)` in
the standalone embedder is to ignore `<uri>` and make the spawnned
isolate from the same AOT snapshot as the main isolate.
This is very confusing and very incorrect.
Instead `Isolate.spawnUri()` should work if-and-only-if the given
`<uri>` points to a valid and compatible AOT snapshot. If not, it should
throw an appropriate exception.
Fixes https://github.com/dart-lang/sdk/issues/48375
Fixes https://github.com/dart-lang/sdk/issues/48326
TEST=vm/dart{,_2}/spawn_uri_aot_test
Change-Id: I279ace08ac1b9a9eed3ae03ebe5d9e2336c1e5c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232603
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Daco Harkes