[RUF027] missing-f-string-syntax has false negatives if calling a function inside brackets or accessing attribute of interpolated variable

[sjdemartini]

With RUF027 enabled, I would expect it to flag both of these, which it currently does not:

1. function calls within the bracketed expression, like print("Hello {foo()}")
2. bracketed expressions that access an attribute of an in-scope variable, like print("Hello {foo.bar}")

Neither of these situations seems to be explicitly part of the listed exceptions to the rule, and don't seem like they should be.

Example:

def fibonacci(n):
    """Compute the nth number in the Fibonacci sequence."""
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fibonacci(n - 1) + fibonacci(n - 2)

class Foo:
    BAR = 5

name = "Sarah"
day_of_week = "Tuesday"

print("Hello {name}! It is {day_of_week} today!")  # Correctly flagged by RUF027
print("Hello {fibonacci}") # Correctly flagged by RUF027

print("Hello {fibonacci(1)}") # Should be flagged by RUF027 but is not
print("Hello {Foo.BAR}") # Should be flagged by RUF027 but is not

Playground: https://play.ruff.rs/ff81d90f-a1d6-4842-8b1b-b31ede9edbaf

[dhruvmanila]

Yeah, this seems like something that we should catch. It could be that we're deliberately ignoring expressions that are not pure variables although I'll have to check the source code to confirm. Thanks for the report.

[MichaReiser]

The rule only flags f-strings referencing a local variable to reduce false positives. This can be found here:

ruff/crates/ruff_linter/src/rules/ruff/rules/missing_fstring_syntax.rs

Lines 207 to 225 in c0b7c36

	if let ast::Expr::Name(ast::ExprName { id, .. }) = element.expression.as_ref() {
	if arg_names.contains(id) {
	return false;
	}
	if semantic
	// the parsed expression nodes have incorrect ranges
	// so we need to use the range of the literal for the
	// lookup in order to get reasonable results.
	.simulate_runtime_load_at_location_in_scope(
	id,
	literal.range(),
	semantic.scope_id,
	)
	.map_or(true, |id| semantic.binding(id).kind.is_builtin())
	{
	return false;
	}
	has_name = true;
	}

We could extend the rule to support more expressions, e.g. attribute access or call expressions. The ideal solution is probably to extract the left-most name and try to lookup that name