When an expression which is not a type, not a constructor, and not an
identifier for a function, is torn off with type arguments, report
DISALLOWED_TYPE_INSTANTIATION_EXPRESSION.
When a function expression (without a name) is explicitly torn off with
the wrong number of type arguments, report
WRONG_NUMBER_OF_TYPE_ARGUMENTS_ANONYMOUS_FUNCTION. This separate error
code has text which does not have a slot for a function's name.
Add resolution for implicit receiver super-type instance method tearoff.
Bug: https://github.com/dart-lang/sdk/issues/46233
Change-Id: I3243e1824e191b6b703b1c995af5e1bd8a242915
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207140
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 465a8a8754.
Reason for revert: Internal issues fixed
Original change's description:
> Revert "[analyzer] Support hints for visibleForOverriding"
>
> This reverts commit 8357efa65c.
>
> Reason for revert: This caused some internal breakage because the annotation is not being used as defined by this CL. There is a path forward, but it requires reverting the CL temporarily. At least one problem is that the annotation is not allowed on a constructor, which is technically valid, but in practice might be something we want to allow anyway. While constructors aren't overridden, they do need to be called from subclasses.
>
> Also, it uncovered a minor problem: when the annotation is applied to an unnamed constructor the message contains an empty name.
>
> Original change's description:
> > [analyzer] Support hints for visibleForOverriding
> >
> > This adds support to detect whether an annotation is
> > `@visibleForOverriding` or whether such annotation is present on an
> > element.
> > Also, the analyzer now reports invalid uses of that annotation (when
> > the annotated member is static, in an extension or private).
> > Finally, we report hints when a member declared with that annotation is
> > uses outside of a method declaration.
> >
> > Closes: https://github.com/dart-lang/sdk/issues/46155
> > Change-Id: I368ea4be6bd5c1da5383a3c9dacdeee02a72af86
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202620
> > Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> > Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
>
> TBR=brianwilkerson@google.com,srawlins@google.com,oss@simonbinder.eu
>
> Change-Id: Ib9731dbebfc41d0d68aac0fb90faf3bd3ac1ef94
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202842
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I6f8090e4a82edd88dc79078c7aa7b9f580ad8162
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203320
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit 8357efa65c.
Reason for revert: This caused some internal breakage because the annotation is not being used as defined by this CL. There is a path forward, but it requires reverting the CL temporarily. At least one problem is that the annotation is not allowed on a constructor, which is technically valid, but in practice might be something we want to allow anyway. While constructors aren't overridden, they do need to be called from subclasses.
Also, it uncovered a minor problem: when the annotation is applied to an unnamed constructor the message contains an empty name.
Original change's description:
> [analyzer] Support hints for visibleForOverriding
>
> This adds support to detect whether an annotation is
> `@visibleForOverriding` or whether such annotation is present on an
> element.
> Also, the analyzer now reports invalid uses of that annotation (when
> the annotated member is static, in an extension or private).
> Finally, we report hints when a member declared with that annotation is
> uses outside of a method declaration.
>
> Closes: https://github.com/dart-lang/sdk/issues/46155
> Change-Id: I368ea4be6bd5c1da5383a3c9dacdeee02a72af86
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202620
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
TBR=brianwilkerson@google.com,srawlins@google.com,oss@simonbinder.eu
Change-Id: Ib9731dbebfc41d0d68aac0fb90faf3bd3ac1ef94
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202842
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds support to detect whether an annotation is
`@visibleForOverriding` or whether such annotation is present on an
element.
Also, the analyzer now reports invalid uses of that annotation (when
the annotated member is static, in an extension or private).
Finally, we report hints when a member declared with that annotation is
uses outside of a method declaration.
Closes: https://github.com/dart-lang/sdk/issues/46155
Change-Id: I368ea4be6bd5c1da5383a3c9dacdeee02a72af86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL adds FFI leaf calls by adding `lookupFunction(.., isLeaf)`
and `_asFunctionInternal(.., isLeaf)`, which generate FFI leaf calls.
These calls skip a lot of the usual frame building and generated <->
native transition overhead.
`benchmark/FfiCall/` shows a 1.1x - 4.3x speed-up between the regular
FFI calls and their leaf call counterparts (JIT, x64, release).
TEST=Adds `tests/ffi{,_2}/vmspecific_leaf_call_test.dart`. Tested FFI tests.
Closes: https://github.com/dart-lang/sdk/issues/36707
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try,vm-ffi-android-release-arm64-try,vm-ffi-android-release-arm-try,vm-ffi-android-product-arm64-try,vm-ffi-android-product-arm-try,vm-ffi-android-debug-arm64-try,vm-ffi-android-debug-arm-try,vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-kernel-win-release-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-precomp-nnbd-mac-release-simarm64-try,vm-kernel-precomp-android-release-arm64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-ubsan-linux-release-x64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try
Bug: https://github.com/dart-lang/sdk/issues/36707
Change-Id: Id8824f36b0006bf09951207bd004356fe6e9f46e
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179768
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In a given library, every import directive has a set of "used
elements," the subset of elements provided by the import which are
used in the library. In a given library, an import directive is
"unnecessary" if there exists at least one other import directive
with the same prefix as the aforementioned import directive, and a
"used elements" set which is a proper superset of the
aforementioned import directive's "used elements" set.
https://github.com/dart-lang/sdk/issues/44569
Change-Id: I4da43be36837cdafb07a0ab67a94e644f351e593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177221
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The two codes had the same message and were for two different ways to
do the same thing, so I don't think it's useful to users to have two
separate codes.
Change-Id: I41933d7cb3050e43ca2555fb75a0432a037d696a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197640
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I started doing this the normal way, but the two codes appear to differ
only based on whether the field was final, and I don't think that factor
is important to the nature of the error, so I think a single code is
sufficient.
Change-Id: I693dcfb1a2a4b47a8b82fe4860e7a61c82ca062e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This paves the way for allowing analyzer and analysis server clients
to format diagnostic message URLs in a special way (e.g. to make them
clickable).
Note that DiagnosticMessage is part of the public API of the analyzer,
so I've retained the old behavior in a deprecated fashion to avoid
breaking clients that don't yet handle diagnostic messages containing
URLs.
See
https://dart-review.googlesource.com/c/sdk/+/193749/comment/86d1ce4b_77a60b1e/
for additional discussion.
Change-Id: Iae9d43a2be7dbc67cb7cb82afe0a7824043d6113
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This changes the span reported from the _receiver_ to
the _use_ (method name, property name, operator token).
I think this change is overall an improvement.
Specifically, its a great improvement for cmdline
output, where the receiver and the "use" are on
different lines.
One possibly weird change is that if the operator is `[]`,
then I only highlight the `[` character. I don't know if
there is a better place, and I think this is fine.
Fixes https://github.com/dart-lang/sdk/issues/43708
Change-Id: Ie66ddf04b4904a367575193106385dd63ee39985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL only changes dart:ffi API, CFE, and analyzer. No VM changes
were needed because the dimensions of inline arrays can be flattened
before passing them to the VM. The multi-dimensionality does not
impact the ABI.
Closes: https://github.com/dart-lang/sdk/issues/45023
TEST=pkg/analyzer/test/src/diagnostics/size_annotation_dimensions_test.dart
TEST=pkg/front_end/testcases/nnbd/ffi_struct_inline_array_multi_dimensional.dart
TEST=tests/ffi/function_structs_by_value_generated_test.dart
TEST=tests/ffi/inline_array_multi_dimensional_test.dart
Change-Id: Ica2c01fccbea7e513879365b34086d8968b54c5b
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-mac-release-x64-try,vm-kernel-nnbd-win-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,analyzer-analysis-server-linux-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188286
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL changes the semantics of
`Pointer<T extends NativeType>.elementAt` and
`sizeOf<T extends NativeType>` to use the compile-time `T` rather than
the runtime `T`.
Issue: https://github.com/dart-lang/sdk/issues/38721
TEST=tests/ffi/data_test.dart
TEST=tests/ffi/sizeof_test.dart
TEST=tests/ffi/structs_test.dart
TEST=tests/ffi/vmspecific_static_checks_test.dart
Change-Id: Ifb25a4bd66d50a385d3db6dec9213b96dff21722
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,analyzer-nnbd-linux-release-try,front-end-linux-release-x64-try,front-end-nnbd-linux-release-x64-try,benchmark-linux-try,dart-sdk-linux-try,pkg-linux-release-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178200
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL updates the parser so that it allows annotations of the form:
`@` <constructorDesignation> <argumentPart>
Where <argumentPart> can contain type arguments. Previously this was
prohibited at parse time.
Generic annotations are still prohibited in the current language
version, but the error is now generated by the parser listener
(BodyBuilder in the case of CFE, AstBuilder in the case of analyzer);
this should open the door for future CLs to add support for generic
annotations when the `generic-metadata` experimental flag is supplied.
Bug: https://github.com/dart-lang/sdk/issues/44838
Change-Id: I90604f38bcb378fc798c5737e486fb26589d4d1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182668
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The type of the `onError` parameter of Future<T>.catchError is just Function,
but the function can either have signature `FutureOr<T> Function(dynamic)` or
`FutureOr<T> Function(dynamic, StackTrace)`. This change adds checks for return
statements in a function literal passed to `onError`, and the return type of a
function-typed expression passed to `onError`.
We still need to check parameter types.
https://github.com/dart-lang/sdk/issues/35825
Change-Id: I806d9d30e595fb9d63ae669f3c30c428b60fdf4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180880
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The type of the `onError` parameter of Future<T>.catchError is just Function,
but the function can either have signature `FutureOr<T> Function(dynamic)` or
`FutureOr<T> Function(dynamic, StackTrace)`. This change adds checks for return
statements in a function literal passed to `onError`, and the return type of a
function-typed expression passed to `onError`.
We still need to check parameter types.
https://github.com/dart-lang/sdk/issues/35825
Change-Id: I3a1d1c444e298c5816fcd1d4bc537f7b87fa3da1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176221
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson