I was thinking about unifying these two codes for documentation purposes,
but then I wondered whether we might not want to unify them for reporting
purposes too. The reason I think it might be better to unify them is
because (a) they really represent a single problem (missing required
arguments) and (b) we were previously reporting the same problem multiple
times.
Change-Id: Iecf2865e67d61b03a1e1f56781e94e283d2a08e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232022
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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>
Jens Johansen