add analyzer warning for unused variables in closures.

[TDuffinNTU]

Firstly, in other languages such as gdscript, if you don't use a variable provided by a parent class's function, you are recommended to preface it with an underscore. Similarly, in dart, if you don't use a variable provided in a closure signature, you can replace it with an underscore instead.

Provider<MyProvider> (
  create: (context) => MyProvider(), // Does not use context at all in this scope.
);

Is also find to be written as

Provider<MyProvider> (
  create: (_) => MyProvider(),
);

It would help enforce style guides if we could enforce this using a linter rule based on similar rules that check ahead for a token's use, and warning the developer if it isn't found later.

---

Conversely, you may run into an issue whereby you manually change these cases as above, but later you modify the contents of the closure to rely on a type that you've renamed, but is otherwise available outside of its scope:

Widget build(BuildContext context) {
  Provider<MyProvider> (
    create: (_) => MyProvider(someProp: context.read<SomeClass>()), // Now MyProvider needs context, but we're actually fetching it from outside its scope in the build method!
  );
}

While this is technically a second request, I think it would be pertinent to also add warnings for this case, too. Currently there is no warning or indication that you may be using variables out of scope which can risk some undefined behaviours (especially if relying on context for stateful objects!) that could be hard to diagnose at a glance.

---

I think these may be offered by some third party packages and/or services. While that might be a good interim solution, an official implementation (maybe of the latter at the very least) is something I would be keen to support. For packages, it can be hard to find one that has what you need (and not what you don't!) and for services there are some that are quite prohibitively expensive for their paid tiers.

[bwilkerson]

... if you don't use a variable provided in a closure signature, you can replace it with an underscore instead.

It would be reasonable to have a lint that would flag positional parameters that aren't used in scope and suggest replacing them with a wildcard. It certainly makes sense for closures. I think it would also make sense for instance methods, but I don't know whether style guides include that recommendation as well.

It doesn't really make sense for top-level or local functions, constructors, or static methods because the better solution there would be to remove the parameter (though we could have an 'unused parameter' warning for that case).

@kallentu  @pq Is it the case that we decided to wait on this lint until we saw how the community wanted to use wildcards, or were there other reasons?

... but later you modify the contents of the closure to rely on a type that you've renamed ...

I'd be concerned about false positive for a lint like this. I suspect that there are valid use cases for ignoring a value passed as a parameter and using a different value of the same type. This is even more likely if the type is a primitive type such as String because of how commonly used those types are.

If there are specific cases, like the case of a context being passed to a constructor, then we could consider a more specialized lint, assuming that it would be less prone to produce false positives.

[kallentu]

Yeah, we did want to wait and see if the community wanted any wildcard variable lints before making them.

Regarding instance methods, we had some discussion of that in #59475.
Making a lint for this for closures seems fine though.