Fix false negative in `avoid_types_as_parameter_names`

[asashour]

Covers the cases for #2770

I am not sure about the documentation request, since this is a test case

m3(f(int)) => null; // LINT

[coveralls]

Coverage increased (+0.0005%) to 95.82% when pulling 2006fb3033927860a58291af7f8ca1c7a1eb3faf on asashour:2770_avoid_types_as_parameter_names into ec373f4fd8a5fcb7dfabfc744df06dec4e3d7fb8 on dart-lang:main.

[srawlins]

I'd be happy to land this, but I'll need conflicts resolved in order to test inside Google first.

[asashour]

Conflicts resolved, thanks.

[srawlins]

Thanks!

Comically, there are a lot of breakages internally; 99% of them are parameters of the form int num, which is for some reason triggered by this PR.

[bwilkerson]

If there are both a type and a name, then it seems reasonable that this lint not fire. As I recall, the motivation for this lint was to prevent cases where someone wrote a type name and forgot to write a parameter name, which clearly isn't the case if the parameter name is there.

[srawlins]

In that case, we might be able to just revert the deleted declaredElement.hasImplicitType && line, and continue.

(There were other breakages in google3 I'll clean up first)

[srawlins]

Ah, now we should change those test cases to have implicit parameter types, if possible. I think the function-typed ones cannot have implicit types. So in void f(int) {}, I've created a parameter named int with type dynamic, but in a function type like void f(void Function<T>(T) callback) {}, there is no parameter named T, there is only an unnamed parameter with type T.

[asashour]

I see, PTAL.

[srawlins]

I'm still working on cleaning this one up internally.

[srawlins]

We are now clean internally.

[pq]

@srawlins: did you happen to look at Flutter too? (No worries either way...)

[srawlins]

Not yet. I hope have a moment this week. 🤞

[pq]

@srawlins: you asked for a change... I think it's done?

[srawlins]

Yes, the one change I requested is done.