Allow annotating top-level or static fields with `@Native` to create
fields backed by native memory.
By using the `_addressOf` operator implemented in the VM, these fields
can be implemented in the CFE by replacing them with accessors looking
up the pointer and then using existing methods to load and store the
value.
Closes https://github.com/dart-lang/sdk/issues/50551
TEST=tests/ffi/native_assets/asset_*_test.dart
TEST=pkg/analyzer/test/src/diagnostics/ffi_native_test.dart
CoreLibraryReviewExempt: VM & dart2wasm only feature
Change-Id: I61dccc88076723d6a6ba02d7fd848b18e4caf780
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338020
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Using `expectStaticType` is a more effective test, because it verifies
that the type is _exactly_ what is expected. It also makes the test
easier to read.
Change-Id: I4b0a22f32601a5dca830a182ff4d37cddd657776
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Instead of implicitly creating closures for FFI
asFunction/lookupFunction APIs in the VM, now they are explicitly expressed in the kernel AST. That makes it possible to analyze
them in TFA.
FFI calls from Dart code into native are now performed in the following way:
```
block {
Pointer #ffiTarget0 = target;
@pragma('vm:ffi:call-closure', _FfiCall<Int32 Function(Int32)>(isLeaf: false))
#ffiClosure0(int arg1) {
_nativeEffect(arg1);
return _ffiCall<int>(#ffiTarget0);
}
} =>#ffiClosure0;
```
_ffiCall method is recognized by the VM and its call is replaced
directly with FFI calling sequence. _ffiCall uses closure
parameters implicitly. No extra trampolines are generated for FFI calls.
TEST=existing
Fixes https://github.com/dart-lang/sdk/issues/54172
Issue https://github.com/dart-lang/sdk/issues/39692
CoreLibraryReviewExempt: Implementation change only.
Change-Id: I92b3ff7391470686151ad0807e2cdbbf1a69d256
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339662
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Now that we no longer need to support legacy (pre-2.12) code in
google3, we don't need to test our support for it either.
Most of our language tests for legacy code were in `tests/language_2`
and have already been deleted; this CL addresses the few tests that
remain in `tests/language`, mostly dealing with "mixed mode" scenarios
(i.e., interactions between legacy code and null safe code).
Change-Id: I023d84547fdf17fb0599c82fbeb4fd07252ccf0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341020
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The dart2wasm compiler treats wasm arrays of objects/ints/floats pretty
much the same, there's no reason to have complicated class hierarchy and
different kinds of wasm array classes.
Also: We rely on all operations on wasm arrays (and other built-in
types) to be handled on the call site. Wasm arrays are not dart objects,
don't support virtual dispatch. So we make operations operating on the
wasm types extensions.
This also makes now loads and stores into the wasm arrays simple `[]` and
`[]=` operations. We still have special extensions for reading/writing
to integer/double arrays that not only read/write but also
sign-extend/zero-extend and operate on Dart's `int` / `double`.
The compiler will allow `WasmArray<X>(length)` for types `X` that have
default-value in wasm arrays (nullable / integer / double types) and
have another `WasmArray<X>.filled(length, X)` for non-nullable reference
types.
Overall this reduces LOCs and simplifies things
Change-Id: I885bed3dfd1c602dc7b0747c69927d464376383d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340881
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
In order to support this, adds necessary changes to conversion
functions (including cast-lists) and makes JSArrayImpl a generic
type.
CoreLibraryReviewExempt: Backend-specific library changes.
Change-Id: I58bcfb67ef21c90be5e25735757d780aac52dc23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337923
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/54192
Callbacks were being casted to their static type before being
called. With generic callbacks, we do not know their exact type
at compile time, therefore cannot make that cast. Similarly, a
null check was being done if the static type of the parameter
was potentially non-nullable, whereas it should be done if it's
*not* potentially nullable.
Change-Id: I3d30e901f1ff2ae4c17887564f15368244baeb24
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340390
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Enables passing inner pointers to typed data in FFI leaf calls.
This works for typed data's in the Dart heap, external typed datas
(constructed from `Pointer.asTypedList`), and typed data views.
Notable implementation details:
1. The Dart signature is used in the Marshaller now. This means it
needs to keep track of whether there's a pointer argument in the
signature (`asFunction`) or not (`@Native`).
2. Unwrapping is done in `FfiCallInstr::EmitNativeCode` before moving
the arguments to their native location. This ensures we can use
the assembler logic to load the `TypedDataBase::data` field.
3. The `XXXList` user visible classes don't have predefined cids.
So the implementation uses symbols for comparison.
4. The type checking logic takes `isLeaf` as input to reject typed
data. This leads to an error message about the type not accepted.
Alternatively, we could consider adding an error message that
specifically says the function should be leaf.
5. To cover all calling convention variants, tests are generated with
up to 20 arguments.
TEST=pkg/analyzer/test/src/diagnostics/ffi_unwrap_typed_data_test.dart
TEST=tests/ffi/unwrap_typeddata_generated_native_test.dart
TEST=tests/ffi/unwrap_typeddata_generated_test.dart
TEST=tests/ffi/vmspecific_static_checks_typeddata_test.dart
Closes: https://github.com/dart-lang/sdk/issues/44589
Change-Id: Ia78f18bf3238d42ac6882929b441f6dc432fcefe
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64c-try,vm-aot-win-release-x64-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-debug-x64c-try,vm-win-release-ia32-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338620
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Addresses some comments in https://github.com/dart-lang/sdk/issues/54192
- With the addition of `nonTypeVariableBound`, we no longer need a
recursive checker.
- We also should account for `StructuralParameterTypes`.
- The current checks did not check type parameters for functions
converted via `toJS`, so that is handled as well.
- Functions that declare type parameters cannot be called in JS
correctly, so an error is added when users try to convert them.
- Some errors are reworded/modified.
Change-Id: Ic05220883ec4ad8653963acd901d339426cba6c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339346
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This will allow users who are implementing their own deferred loading mechanism
to batch all the loads for a specific library. Today in order to do batching users have to gather the URIs passed to the `dartDeferedLibraryLoader` hook in a list and schedule (e.g. via setTimeout) a load for some future task.
The need to schedule a task has been shown to cause delays in IPL. But loading each part file individually can also be very expensive. So this allows for a compromise where bundling can be done synchronously per loaded library.
Adds ~8kB to unminified main files and ~2.5kB to minified main files.
Bug: https://github.com/dart-lang/sdk/issues/54202
Change-Id: I623643b03920988cda8b0f8b297944be35ffa606
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340480
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
A quirk of analyzer and CFE implementations is that they resolve
property gets such as `foo.bar` to specific field or getter
declarations that may be not be directly defined on the target type;
for example if `foo` has type `B`, and `B` extends `A`, and `A`
contains a field called `bar`, then `foo.bar` is considered to refer
to `A.bar`, for example:
class A {
int? bar;
}
class B extends A {}
f(B foo) {
print(foo.bar); // Resolved to `A.bar`.
}
This is in contrast with the language specification, which makes a
clean distinction between class _declarations_ and the _interfaces_
implied by those declarations. While a class declaration can contain
(among other things) both getters and fields, which might be concrete
or abstract, an interface doesn't distinguish between getters and
fields, and is inherently abstract.
The advantage of the analyzer/CFE approach is that it allows more
intuitive error messages and "go to definition" behavior, which
benefits users. But it has some ill-defined corner cases involving
complex class hierarchies, because not every property access can be
resolved to a unique declaration (sometimes a getter is multiply
inherited from multiple interfaces, for example). The language spec
approach has the advantage of being well-defined and consistent even
in situations involving complex class hierarchies.
When I initially implemented field promotion, I took advantage of this
quirk of the analyzer and CFE implementations, so that I could make
property gets that refer to field declarations promotable, while
keeping property gets that refer to abstract getter declarations
non-promotable. This caused unpredictable behaviors in the ill-defined
corner cases. It also meant that in certain rare cases, a property
access might not be promoted even when it would be sound to do so
(e.g. a property access might refer to a private abstract getter
declaration, but the only concrete _implementation_ of that abstract
getter was a final field).
This CL changes the rule for promotability so that any get of a
private property is considered promotable, provided that the
containing library doesn't contain any concrete getters, non-final
fields, or external fields with the same name. It no longer matters
whether the private property refers to a field or a getter. This rule
is simpler than the old rule, restores the spec's clean distinction
between class declarations and interfaces, and allows more promotions
without sacrificing soundness.
For additional details please see the breaking change announcement at
https://github.com/dart-lang/sdk/issues/54056, as well as the original
change proposal at https://github.com/dart-lang/language/issues/3328.
Fixes https://github.com/dart-lang/sdk/issues/54056.
Fixes https://github.com/dart-lang/language/issues/3328.
Change-Id: I38ffcb9ecce8bccb93b1b2586a1222a0fb1005a7
Bug: https://github.com/dart-lang/sdk/issues/54056
Bug: https://github.com/dart-lang/language/issues/3328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337609
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change implements one of the features of experimental feature
`inference-update-3`: with the experimental feature enabled,
assignments to local variables use the declared (or inferred) type of
the local variable as the context for evaluating the RHS of the
assignment, regardless of whether the local variable is promoted. With
the experimental feature disabled, assignments to local variables
continue to use the promoted type of the local variable as the context
for evaluating the RHS of the assignment.
This eliminates one of the scenarios in which the context type of an
assignment is "aspirational" (i.e., not required to be met in order to
prevent a compile time error). Once all aspirational context types
have been removed from the language, we will be able to re-work
coercions to be based on context type, which fixes a number of
usability footguns in the language. See
https://github.com/dart-lang/language/issues/3471 for details.
Bug: https://github.com/dart-lang/language/issues/3471
Change-Id: Ic07ac1810b641a9208c168846cd5fd912088d62b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338802
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Removes @staticInterop JS types declarations in favor of
typedefs (the function types' reified types and the typed data's
reified types have changed to make the type hierarchy work in the
JS backends).
- Adds extension types to dart:js_interop
- Adds a fromInteropObject helper to JSObject to avoid casting to
an extension type
- Deletes now stale tests
- Refactors some dart2wasm @staticInterop declarations since they
can no longer implement JS types
- Updates extension types tests to use the prefix extension_type
instead of inline_class
- Updates comments
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ibe04afac9585ddb99fcf6dbaa7f12050d8b876dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332860
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This adds the `Native.addressOf` function, which takes a constant tear-
off of a method annotated with `@Native` as a parameter and returns a
pointer to the underlying C function.
The CFE will resolve these calls in two steps: First, the existing
transformer for `@Native` methods adds a pragma describing the fully-
resolved native annotation (with the asset id inferred from the library
if not given explicitly). Then, the FFI use sites transformer rewrites
calls to `Native.addressOf` by searching for this pragma on the passed
function and passing the `Native` constants to `Native._addressOf`. The
latter method is implemented in the VM, which can re-use existing parts
already used for `@Native` calls.
An alternative implementation strategy would have been to forward
`addressOf` calls to `Native.ffi_resolver_function` directly without
any special consideration in the VM. However, the chosen approach makes
it easier to support static linking in the future, as this requires
unresolved symbols in the generated assembly.
Closes https://github.com/dart-lang/sdk/issues/50552
TEST=pkg/vm/testcases/transformations/ffi/ffinative.dart
TEST=tests/ffi/native_assets/asset_*_test.dart
TEST=tests/ffi/vmspecific_static_checks_ffinative_test.dart
TEST=pkg/analyzer/test/src/diagnostics/ffi_native_test.dart
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64c-try,vm-aot-win-release-x64-try,vm-kernel-precomp-linux-release-x64-try
CoreLibraryReviewExempt: VM & dart2wasm only feature
Change-Id: Ic8e3a390146dffd44c95578f975a4472db79a0ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Protect VM compiler code from crashing when incorrect
type arguments are passed to FFI _asFunctionInternal.
Also, improve front-end FFI checks to reject Function
as a Dart type corresponding to a NativeFunction<...>
(it should be an actual function type).
TEST=tests/ffi/vmspecific_static_checks_test.dart
Fixes https://github.com/dart-lang/sdk/issues/52730
Change-Id: I02c012bb76d5c94f551da2c725a476b68c0f9db4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339109
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Shikhar Soni