Rule idea: use of a non-string literal as the assert message

[Lokejoke]

While reviewing the results of the ruff-ecosystem rule use-implicit-booleaness-not-len (PLC1802), I came across an interesting case here.

It appears to involve the unintentional use of a non-string literal in an assert statement’s message, which I believe is an oversight. It seems like the intention was to use a syntax similar to matches!(expr1, expr2).

I haven’t found any specific linting rule that addresses the second argument of an assert statement.

---

Rule name idea: non-string-literal-assert-message
However:

• This name might suggest anything other than a string literal.
• Alternatively, literal that is not a string.

I would love to implement this rule if approved.

Any thoughts on this?

[MichaReiser]

This sounds interesting. I don't know how common this error is and, thus, if it justifies being its own rule. But we could figure that out by implementing the rule.

Ruff does have one rule that asserts on the second argument, https://docs.astral.sh/ruff/rules/assert-with-print-message/#ruff-specific-rules-ruf

I do think that implementing this rule proper requires type inference because there are many patterns where a non-string-literal message is valid:

error = "..."

assert a == b, error 
assert a == b, create_error()
assert a == b, x.error

It's easier to detect the invalid patterns with type inference because we can then answer whether the expression used in the error position evaluates to a string and, if not, it's probably an incorrect use that we can flag.

For now, I think the best we could do is to flag usages where the second argument is any literal other than string. But whether this is common enough (and useful) to still warant it's own rule is hard to say