It was not necessary for this argument to support both `String` and
`DartType`; we can ensure that we always pass in a `DartType` by
calling `ClassElement.thisType`.
Change-Id: I94ac2fed7495b8267edea003d1fd088649c2d4a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217620
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Replace `identifier` field with `expression`, which means deprecating
`identifier`, redirecting users to `expression`. For now, `expression`
always returns an Identifier. In a future breaking release, it will
return other CommentReferableExpressions.
* SimpleIdentifier, PrefixedIdentifier, PropertyAccess,
ConstructorReference, FunctionReference, and TypeLiteral are all
CommentReferableExpressions, but support is not implemented yet to
parse CommentReferences with those contained expressions.
Bug: https://github.com/dart-lang/sdk/issues/47444
Change-Id: I1905afecf3878cd7dca6e275ef0a2ab80500eb4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216320
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
This is a re-land for https://dart-review.googlesource.com/c/sdk/+/217880.
The primary difference is the call-sites of
insertGenericFunctionInstantiation. There are more, and many more test
cases.
This is a non-breaking change (when analyzing code at language version
2.14 and earlier). If constructor-tearoffs is enabled (language version
2.15), then FunctionReference nodes are inserted, to represent generic
function instantiation. Constant evaluation can then use the
`typeArgumentTypes` to instantiate arbitrary function-typed
expressions.
If constructor-tearoffs is not enabled, generic function instantiation
continues to take place at a SimpleIdentifier, PrefixedIdentifier, or
PropertyAccess only, with constant evaluation using
SimpleIdentifier.tearOffTypeArgumentTypes.
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: Icf876cb6866bc1030e0cefaaafe221757d5b5639
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218221
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 1c8f56fb13.
Reason for revert: This breaks package:collection at
ListComparableExtensions.binarySearch, at
`comparable ?? compareComparable`:
The argument type 'Function' can't be assigned to the parameter type
'intFunction(E, E)'. #argument_type_not_assignable
Original change's description:
> Implement Generic Function Instantiation via wrapping node
>
> This is a non-breaking change (when analyzing code at language version
> 2.14 and earlier). If constructor-tearoffs is enabled (language version
> 2.15), then FunctionReference nodes are inserted, to represent generic
> function instantiation. Constant evaluation can then use the
> `typeArgumentTypes` to instantiate arbitrary function-typed
> expressions.
>
> If constructor-tearoffs is not enabled, generic function instantiation
> continues to take place at a SimpleIdentifier, PrefixedIdentifier, or
> PropertyAccess only, with constant evaluation using
> SimpleIdentifier.tearOffTypeArgumentTypes.
>
> Bug: https://github.com/dart-lang/sdk/issues/46020
> Change-Id: Ie370c00c8a2ce7a4791ac9cdb7459a01339a79c1
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217880
> Commit-Queue: Samuel Rawlins <srawlins@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
TBR=scheglov@google.com,brianwilkerson@google.com,srawlins@google.com
Change-Id: Ie76cd703e05cbf65fecaa76b72e829f8272b8307
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/46020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218089
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is a non-breaking change (when analyzing code at language version
2.14 and earlier). If constructor-tearoffs is enabled (language version
2.15), then FunctionReference nodes are inserted, to represent generic
function instantiation. Constant evaluation can then use the
`typeArgumentTypes` to instantiate arbitrary function-typed
expressions.
If constructor-tearoffs is not enabled, generic function instantiation
continues to take place at a SimpleIdentifier, PrefixedIdentifier, or
PropertyAccess only, with constant evaluation using
SimpleIdentifier.tearOffTypeArgumentTypes.
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: Ie370c00c8a2ce7a4791ac9cdb7459a01339a79c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217880
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
The general direction is to make pieces of data that are produced
together to be stored together, and so be available together.
_FileStateLocation is created before FileState, so it is separated.
Any FileState has some unlinked state, so we pass _FileStateUnlinked
into the constructor. In Cider we don't refresh files, we discard
them and recreate. So, '_unlinked' is a final field.
Practically FileState works as a wrapper around _FileStateUnlinked.
It could probably have been inlined into FileState. My excuse for
not doing this is that in DAS, at least at the moment, we keep
FileState instances and refresh them with replacing their unlinked
states. So, they should be separate objects.
Change-Id: I9439a4021e6efa9e4375eceb5eecf534eabda168
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This will allow tests to verify multiple substrings are present in the
error message without having to include all the intervening text
(which would make the tests brittle).
Change-Id: I8aeaa7edb7b6da0eadf8c12e8c01d7e0805d9b27
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217822
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes half a dozen tests for
https://github.com/dart-lang/sdk/issues/46020
Fixes https://github.com/dart-lang/sdk/issues/47471
Fixes https://github.com/dart-lang/sdk/issues/47366
There are two cases where implicit tear-off conversion should be
performed in desugared code. Because the analyzer does not desugar,
we just make additional checks in assignability:
* for-in statements, where the iterable is an Iterable<C> and C is
a callable class, and the for-in element is function-typed.
* spread-elements, where the iterable is an Iterable<C> and C is
a callable class, and the typed literal element type is a
function type.
This is a breaking change as it involves removing implicit tear-off
conversion from TypeSystem.isAssignableTo.
However, it passes google3 today. :D
Change-Id: I9d852adadc11c92b3f7dbf130965d003c68b2b14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217157
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Metadata is attached to a `VariableDeclarationList`, not the individual
declarations therein.
Even though annotations from the list are copied down into the local
variable elements, the resolver did not set the `element` property on
those annotations which is required for computing the constant value in
a later step.
This is fixed by making the resolver visit the declaration list instead
of individual declarations.
Closes https://github.com/dart-lang/sdk/issues/47502
Change-Id: Id6e47e6fa878e61be5279fa4127262deb73ab1c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217363
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
The errors HintCode.INVALID_VISIBLE_FOR_OVERRIDING_ANNOTATION and
CompileTimeErrorCode.EXTENSION_CONFLICTING_STATIC_AND_INSTANCE didn't
really need to name the enclosing declaration, since the user can
easily find the enclosing declaration from the location of the error
message. Without this change, there are some situations where an
error message would awkwardly refer to an unnamed extension as having
the name `<unnamed>`.
Change-Id: I4ddec389f18e78167464b1b5c35556e92dd1c15f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This changes the behavior of the
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR error
so that instead of referring to unnamed constructors with a clumsy
trailing `.` (e.g. `The constructor 'Foo.'`), it refers to them in the
same way the user's code refers to them (so, e.g. if the user's code
refers to the constructor using the name "new", the error message does
too).
Change-Id: Ib29b64ce0122d8928b3a59f5e0125561da8f73d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216840
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, if a piece of code inside an extension tried erroneously
to refer to a static class member using instance access, the error
CompileTimeError.UNQUALIFIED_ACCESS_TO_STATIC_MEMBER_OF_EXTENDED_TYPE
would be reported. This change corrects the error to
CompileTimeError.INSTANCE_ACCESS_TO_STATIC_MEMBER.
In addition, the responsibility to report the error
CompileTimeError.INSTANCE_ACCESS_TO_STATIC_MEMBER is shifted fully to
the resolver (previously, it was split between the resolver and the
error verifier).
Change-Id: Idcd1a3b8a1e226fed692900838c3d2d3c0585d4f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We now print any non-null values of `ExpectedError.message`,
`ExpectedError.messageContains`, and
`ExpectedError.correctionContains`. This should make it easier to
understand what has gone wrong when there's a mismatch due to an
incorrect message or correction string.
Change-Id: I50359008ad15b894b1a5c5512ff6847d07193408
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216820
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry