Check for late-binding closures (e.g. lambdas) in loops

[Zac-HD]

We just got bitten by the classic late-binding of loop variables used in lambdas at work, and I'd like to make sure this doesn't happen again.

Specifically, it should be an error to use any loop variable inside the body of a function (whether lambda ... or def ...) defined inside that loop, unless the same name is a parameter of that function. e.g. for x in ...: fns.append(lambda x=x: x**2) would be OK, but lambda: x**2 would not.

Loops include (async) for loops, and list/set/dict/generator comprehensions; but exclude while-loops as they have no clearly associated loop variables. While this can still be buggy, I'd like to keep the false-alarm rate as low as reasonably possible.

Related: #79, #175, and the much noisier wemake-style-guide LambdaInsideLoopViolation.

[carljm]

Seems the rule should be no reference inside the nested function or lambda to any variable from enclosing scope that is reassigned within the loop, not just the loop index variable? That seems doable, will catch more cases, and still not as noisy as forbidding all lambdas in loops.