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>
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>
Paul Berry