This CL adds support for users defining integers which are mapped to
differing sizes and signedness based on the application binary interface
the Dart VM is running on.
Notable implementation design decisions:
- ABIs are open world, so that adding an ABI to the Dart VM does not
break existing definitions. Thus, we only figure out in the VM that
we're missing a mapping. We throw compile-time errors.
- In AOT, these show up in the precompilation step.
- In JIT, these show up as `_CompileTimeError` at runtime. Note that
these can be caught. So in subsequent compilation steps we need to
ensure that we also throw the same compile-time error.
- We match on the call-sites (streaming_flowgraph_builder) rather than
method bodies (kernel_to_il) of AbiSpecific loads and stores so that
we can compile for the int-size of the call site.
API design decisions:
https://github.com/dart-lang/sdk/issues/42563#issuecomment-981774001
Closes: https://github.com/dart-lang/sdk/issues/42563
TEST=tests/ffi_2/abi_*_test.dart
TEST=tests/ffi/function_*_generated_test.dart
TEST=tests/ffi/vmspecific_static_checks_test.dart
Change-Id: I8c8df36fab939b6fb614c5f1ee8e1bf46b6e9521
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,analyzer-nnbd-linux-release-try,app-kernel-linux-debug-x64-try,benchmark-linux-try,dart-sdk-linux-try,front-end-linux-release-x64-try,front-end-nnbd-linux-release-x64-try,pkg-linux-debug-try,vm-canary-linux-debug-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-fuchsia-release-x64-try,vm-kernel-checked-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-linux-debug-x64c-try,vm-kernel-mac-debug-x64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-win-debug-x64-try,vm-kernel-nnbd-win-release-ia32-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-android-release-arm64c-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-precomp-ffi-qemu-linux-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221501
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Fixes https://github.com/dart-lang/sdk/issues/45958
Move check out of old checker.dart, into (less old) error_verifier.dart
and move test case out of old checker_test.dart. Add valid test case.
Rename INVALID_SUPER_INVOCATION to SUPER_INVOCATION_NOT_LAST, and
correct comment on that code (it has a parameter).
Do not duplicate report that code with MULTIPLE_SUPER_INVOCATIONS or
with SUPER_IN_REDIRECTING_CONSTRUCTOR.
Change-Id: I26e28b345fd8cef8ed2c9ec89ab12b56ea1c2f37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This change ensures that the only types ever passed to ErrorReporter
arguments are String, DartType, int, Uri, or Element. A few call
sites had to be changed so that instead of passing in AST nodes they
passed in the result of calling `toString` on those AST nodes.
In future CLs, I plan to move toward a system where instead of passing
the message arguments to ErrorReporter as a list of `Object`, we call
a `withArguments` method that's specific to each error; that method
will have a specific list of argument types that it supports, so that
if we accidentally pass the wrong things into an error message, the
problem will be detected at compile time (instead of the user just
seeing a confusing error message).
The `withArguments` methods will be code generated from annotations in
the analyzer's `messages.yaml` file. Keeping the set of types
supported by those `withArguments` messages small should help simplify
the code generation process, and provide flexibility for how errors
are represented in the future.
Change-Id: I4a793db2fe5b1344199b770898634b61be41ad11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216301
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a new HintCode for code in which comment-references is enabled.
`/// See also [new List].` is marked as deprecated, preferring a direct
reference (or "tear-off") of a constructor, like
`/// See also [List.new].`.
Additionally, a new quick fix supports making the above conversion,
taking into account both unnamed and named constructors.
Bug: https://github.com/dart-lang/sdk/issues/47446
Change-Id: Iec68ef21bd03198ea822979f6f0048cc655023c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217400
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Cases where `null` was being passed as an argument to formatting a
message have all been fixed in previous CLs; all that remains to do is
change the type system to reflect that, and insert `!`s in a few
places.
This brings us one step closer to being able to make analyzer message
formatting type safe.
Change-Id: Id9e0d0b32f29cde0fdc5227417b7a2e3fc3b443d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216272
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Two error messages are affected:
1. When the user tries to access a static member of an extension
through an instance of a class that mentions the extension's "on"
type, and that extension is unnamed, we now report
INSTANCE_ACCESS_TO_STATIC_MEMBER_OF_UNNAMED_EXTENSION instead of
INSTANCE_ACCESS_TO_STATIC_MEMBER. The new error message is the same
as the old one (and uses the same sharedName), but it omits the
correction message suggesting to the user that they try accessing the
static method directly via the extension name, since this advice
doesn't apply.
2. When we report AMBIGUOUS_EXTENSION_MEMBER_ACCESS, if one of the
ambiguous members comes from an unnamed extension, we now report the
unnamed extension as "unnamed extension on '$type'" rather than
referring it to as an extension named `<unnamed>`.
Change-Id: I3ca3a1ccc9399b26b083040de20db8e4f691be32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217102
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- Allows FfiNative annotation to be attached to non-static
methods of classes.
- Transforms non-static instance methods to static, adding
wrappers with the receiver as an extra, implicit first paramters.
- Transform all parameters and arguments to Pointer if the object
being passed supports it (i.e. extends NativeFieldWrapperClass1).
- Adds compile time errors for cases where the FfiNative annotation
doesn't align with the annotated function. Taking into account
implicit receivers and converted Pointers.
- Adds complimentary Analyzer checks for the above errors as well.
- Adds tests for the transforms, compile time errors and analyzer
changes.
TEST=Adds new tests for instance methods, analyzer changes.
Change-Id: Idf54430acf2728a650008333b149b254941290ad
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213773
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This change standardizes most of the analyzer to refer to problem
messages and correction messages using the names `problemMessage` and
`correctionMessage` (consistent with the naming convention used in the
analyzer and CFE `messages.yaml` files).
Change-Id: I72f078a368c65b346626f560cc721fcff4836452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215151
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Our understanding improved, and out approach changed significantly.
So, this existing implementation is different enough to be not
very useful anymore. And it gets in my way while doing other changes.
Change-Id: If31c20a0a6f86c01a58d16390a989f77962396b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously, if a CFE error contained a placeholder (such as
`#string`), that wasn't converted to the equivalent analyzer
placeholder, which meant that analyzer error reporting logic needed to
know whether the error being reported came from the CFE or the
analyzer in order to report the error correctly, otherwise the
placeholder text would just show up verbatim in the analyzer output.
Change-Id: If875de3a1a80048700b0edf458377c5fc87a15d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213281
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously we had identified this error with the analyzer error code
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR, but
they're not the same error at all. As a result, code like this:
var x = new a.b.c<C>();
would lead to the bogus analyzer error text "The constructor '{0}.{1}'
doesn't have type parameters." (with the placeholders "{0}" and "{1}"
visible to the user).
With this change, the error text is the same as that from the CFE: "A
constructor invocation can't have type arguments after the constructor
name."
Change-Id: Ib69d1ff8f7089e59b71d2dcd9a8ec51edffd94dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This code is a little weird because of how this type instantiation
works:
```
typedef Fn<T> = void Function(T);
var x = Fn<int>.foo;
var y = (Fn<int>).foo;
extension on Type {
int get foo => 1;
}
```
`x` is illegal under any circumstance, because calling a getter on a
type instantiation can _only_ resolve to a constructor, but function
types do not have constructors. But it's nice to resolve what we can,
and what the user may have meant, and we have to represent
`Fn<int>.foo` _somehow_. So it's a property access on a TypeLiteral.
Add two new codes because it is not correct to say that `foo` is not a
getter on 'Type' because that is beside the point. The issue is that
there is no possible getter on a type-instantiated type literal of
a function type alias (nor method, nor setter).
Add lots of tests, for calling a method, a getter, and a setter on a
function type alias literal. Add tests with prefixes, bounds, too
many and too few args.
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: Icdf17506a64b3382226c5e50786784130d9e3bf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213287
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This requires adding `isConst` to the ConstructorReference AST node,
which I think is appropriate, as it they can be in a constant context,
and we choose to report errors based on this state.
Change-Id: I4649c73a8bb3c2651a0e28838f0fc82574ce1622
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212603
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov