ParameterElementImpls returned from GenericFunctionTypeElement's parameters method always return as equal to each other

[jcollins-g]

In the case where GenericFunctionTypeElement is being used in a new style generic function type declaration, e.g.:

/// A typedef with the new style generic function syntax.
typedef NewGenericTypedef<T> = List<S> Function<S>(T, int, bool);

the corresponding GenericFunctionTypeElement correctly generates three different parameter objects, one each for T, int, and bool.

However, each of them have the same hashCode and compare as equal to each other, which can confuse dartdoc's internal object cache. This results in all three looking like 'T'.

[jcollins-g]

Tested with analyzer package 0.30.0.

[jcollins-g]

Similarly, this problem crops up in cases like:

/// This class has a complicated type situation.
abstract class TypedFunctionsWithoutTypedefs {
  void Function(T1, T2) getAFunctionReturningVoid<T1, T2>(
      void callback(T1 argument1, T2 argument2));
}

The return type winds up being documented as Function(T1, T1) due to dartdoc's object cache being subverted.

These patterns are starting to be used in the SDK and elsewhere now so the impact of this bug is increasing.

[jmesserly]

I believe this happens because they have no name. The == and hashCode for Elements looks at the fully qualified name, essentially enclosing scope+item name. So they'll compare equal because they all have no parameter name.

I think TypeParameterElements have a similar problem when we make synthetic ones (for synthetic function types). In that case, they've got their name but they don't have an enclosing scope, so every synthetic type parameter with the same name will compare equal to every other one (two unrelated variables T and T will compare equal). Some notes on that issue here: #29778 (comment)

[jcollins-g]

I think I've convinced myself that dropping caching for Parameter ModelElements is safe in dartdoc, so I will do that to work around this problem.

[jcollins-g]

I'm having to work around this in another way for dart-lang/dartdoc#1835.