commit e9e761644d9954faa740901e1eb6b6e71a9003f6
author Paul Berry <paulberry@google.com> Tue Oct 01 16:08:52 2024 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Oct 01 16:08:52 2024 +0000
tree 08d7eb89062cb4a57540950f9a76f6768e201818
parent c4a77dce652b074efd21785ab5b35e822e3cf4c7

[analyzer][cfe] Share constraint generation for non-generic function types

This change combines function-handling logic from the analyzer's
`TypeConstraintGatherer._functionType0` and the CFE's
`TypeConstraintGatherer._isNullabilityAwareSubtypeMatch` methods into
`TypeConstraintGenerator.performSubtypeConstraintGenerationForFunctionTypes`,
which is in `_fe_analyzer_shared`.

The CFE and the analyzer have some pretty significant differences in
how they represent function types:

- In the analyzer, all function parameters are in a single
  `parameters` list; each element of this list (of type
  `ParameterElement`) can be queried to find out if it is named or
  unnamed, and if it is required or optional. A convention enforced
  partially by the `FunctionType` constructor is that the `parameters`
  list stores reqired unnamed parameters first, then either optional
  unnamed parameters or named parameters; named parameters are sorted
  by name. The analyzer provides additional getters
  `namedParameterTypes`, `normalParameterNames`,
  `normalParameterTypes`, `optionalParameterNames`, and
  `optionalParameterTypes`, which provide other views of this
  information (for example, `namedParameterTypes` contains just the
  named parameters, as a map from name to `ParameterElement`).

- In the CFE, unnamed and named parameters are in two separate lists
  (`positionalParameters`, of type `List<DartType>`, and
  `namedParameters`, of type `List<NamedType>`); in
  `positionalParameters`, required parameters come before optional
  ones. A single integer (`requiredParameterCount`) indicates how many
  elements of `positionalParameters` are required, and by convention,
  `namedParameters` is sorted by name.

In order to share logic between these representations, I had to come
up with a common API that these two representations could be easily
adapted to. The analyzer's representation proved to be easier to
adapt, so I based the common API mostly on the CFE's representation,
but with some name changes for clarity. The shared API is:

- `positionalParameterTypes` gets a list of positional parameter types

- `requiredPositionalParameterCount` tells how many entries in
  `positionalParameterTypes` are required.

- `returnType` gets the function type's return type.

- `sortedNamedParameters` gets a list of information about named
  parameters. The list elements are sorted by name, and each element
  of this list is of type `FunctionParameterStructure` (a common
  interface implemented both by the analyzer's `ParameterElement` and
  the CFE's `NamedType`).

- `typeFormals` gets a list of the function type's formal type
  parameters.

To minimize the performance impact of adapting the analyzer to this
API, the analyzer computes `positionalParameterTypes`,
`requiredPositionalParameterCount`, and `sortedNamedParameters` at the
time a `FunctionType` is constructed. Hopefully this should not be too
much of a performance hit, since doing so does not take too much more
effort than checking that the named parameters are sorted (which the
`FunctionType` constructor was already doing).

This is based on previous work by Chloe Stefantsova in
https://dart-review.googlesource.com/c/sdk/+/386480.

Change-Id: Iefe18d72771146399d81747ceab9c929516b0523
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386322
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>