[pylint] Implement unnecessary-lambda (W0108)

[clemux]

This is my first PR and I'm new at rust, so feel free to ask me to rewrite everything if needed ;)

The rule must be called after deferred lambas have been visited because of the last check (whether the lambda parameters are used in the body of the function that's being called). I didn't know where to do it, so I did what I could to be able to work on the rule itself:

• added a ruff_linter::checkers::ast::analyze::lambda module
• build a vec of visited lambdas in visit_deferred_lambdas
• call analyze::lambda on the vec after they all have been visited

Building that vec of visited lambdas was necessary so that bindings could be properly resolved in the case of nested lambdas.

Note that there is an open issue in pylint for some false positives, do we need to fix that before merging the rule? pylint-dev/pylint#8192

Also, I did not provide any fixes (yet), maybe we want do avoid merging new rules without fixes?

Summary

Checks for lambdas whose body is a function call on the same arguments as the lambda itself.

Bad

df.apply(lambda x: str(x))

Good

df.apply(str)

Test Plan

Added unit test and snapshot.
Manually compared pylint and ruff output on pylint's test cases.

References

• pylint documentation
• pylint implementation
• Implement Pylint #970

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

[charliermarsh]

Before I get deep into the review, do you mind skimming through some of the ecosystem checks and confirming that the implemented behavior matches Pylint's?

[clemux]

There are a few less errors with ruff than with pylint in pandas. For example, this:

    expected2 = frame_or_series(rolling.apply(lambda x: np_func(x, **np_kwargs)))

I might be missing something but I'd say it's a bug in pylint. I'll look into it.

[clemux]

Issue submitted on pylint side: pylint-dev/pylint#9148

[clemux]

I don't expect you to accept that, but I couldn't figure out how to make it work otherwise :)

[charliermarsh]

Going to tweak this a bit, but the idea makes sense :)

[zanieb]

New rules should be added in RuleGroup::Preview then stabilized in a later release. We can improve the naming of the stable rule group :)

[clemux]

Done.

[charliermarsh]

Gonna review this today, sorry for the delay.

[charliermarsh]

So the reason that lookup_symbol didn't work here is a bit hard to explain, but consider:

_ = lambda x: f(lambda x: x)(x)

Here, we're trying to see if f(lambda x: x) contains any references to the x in _ = lambda x. If we use lookup_symbol, it will try to resolve the inner x relative to the outer scope, that of _ = lambda x, so it thinks it's a reference to the outer x. Using resolve_name ensures that we use the correct binding which was already computed in the binding phase.