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>
I'm preparing for the situation where an expression of (almost) any kind
could be wrapped with a generic function instantiation, and I was very
worried that there were a lot of cases like this:
var localVariable = node.childNode;
localVariable.accept(_resolver);
// Do more with localVariable.
This is dangerous because localVariable may no longer be the same node
as `node.childNode`. I searched eerywhere I could for dangerous cases
like this. In some cases, I follow the middle statement with
`localVariable = node.childNode`, which is a common practice. In other
cases, the local variable was only referenced 2 or 3 times, and was
unnecessary. In other cases, I saw that the node strictly referred to
statements or other types of nodes, like a CatchClause. I am
reassured though that there really wasn't too much code like this.
I'd love to figure out how to enforce this statically, but haven't
found a good solution.
Change-Id: If38124dc2036b6f04879a065d66bf3ea73e68977
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218184
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
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>
Paul Berry