FURB118 breaks program

[kaddkaka]

Summary

what kind of breakage is ok for unsafe fixes?

This rule suggests a change from lambda to itemgetter that will fail:

def func(rows):
    rows.sort(key=lambda x: x[1])
    rows.sort(key=lambda x: x[x.find("=")])  # <- Why doesn't it try to convert this line?
    rows.sort(key=lambda x: (x[x.find("=")], x[1]))  # <-- this remove the `x` but still keep it in the itemgetter code

This might be a unusual case that is "ok" to break. (But it is an actual case I found in code the other day).

As the second line above doesnt get incorrectly fix, I'm guessing there is some detection to avoid applying the fix when the x itself is used in the braackets.

Suggestion: detect if the lambda argument itself (x) is used inside the brackets, and skip applying the fix.

Example output from ruff 0.14.10:

$ ruff --isolated check --fix ~/tmp/bugreport_ruff_refurb118_itemgetter.py --select FURB118 --preview --show-fixes
FURB118 Use `operator.itemgetter(1)` instead of defining a lambda
 --> /home/david/tmp/bugreport_ruff_refurb118_itemgetter.py:2:19
  |
1 | def func(rows):
2 |     rows.sort(key=lambda x: x[1])
  |                   ^^^^^^^^^^^^^^
3 |     rows.sort(key=lambda x: x[x.find("=")])
4 |     rows.sort(key=lambda x: (x[x.find("=")], x[1]))
  |
help: Replace with `operator.itemgetter(1)`

FURB118 Use `operator.itemgetter(x.find("="), 1)` instead of defining a lambda
 --> /home/david/tmp/bugreport_ruff_refurb118_itemgetter.py:4:19
  |
2 |     rows.sort(key=lambda x: x[1])
3 |     rows.sort(key=lambda x: x[x.find("=")])
4 |     rows.sort(key=lambda x: (x[x.find("=")], x[1]))
  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
help: Replace with `operator.itemgetter(x.find("="), 1)`

Found 2 errors.

Version

0.14.10

[ntBre]

Thank you for the report and for the nice example! It looks like your diagnosis is exactly right. In direct subscripts, we check if the argument is used within the subscript:

ruff/crates/ruff_linter/src/rules/refurb/rules/reimplemented_operator.rs

Lines 285 to 288 in f055f39

	// The subscripted expression can't contain references to the argument, as in: `lambda x: x[x]`.
	if any_over_expr(expr.slice.as_ref(), &|expr| is_same_expression(arg, expr)) {
	return None;
	}

but I don't think we apply the same check recursively when fixing a tuple on a separate code path:

ruff/crates/ruff_linter/src/rules/refurb/rules/reimplemented_operator.rs

Lines 296 to 298 in f055f39

	/// Return the `operator` implemented by given tuple expression.
	fn itemgetter_op_tuple(
	expr: &ExprTuple,

I would definitely consider this a bug.