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>
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>
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>
Sam Rawlins