Rule: Auto-add -> None typehint to functions

[intgr]

Summary

WIP: This is a very early partial draft still. No need to do serious review yet, but feel free to give me pointers.

I want to create a new Ruff rule that auto-adds -> None return type hint to functions when no return <value> statements are present in the function.

Clearly there are lots of special cases I need to handle (yield, raise, @overload, .pyi files, etc).

I currently used rule code RUF300, which is unprecedented. But I think it may make sense to allocate a specific RUF range for typehinting-related rules. I have a few more ideas similar to this one.

• Related issue: Rule proposal: Auto-add -> None typehint to functions #8213

Test Plan

TBD.

[intgr]

Also some relevant points here that I should consider:

• PLR1711, RET501 should exempt annotated function where return type isn’t -> None #3704

[diceroll123]

Might need to special case NoReturn, not limited to the following:

[charliermarsh]

I haven't had a chance to review the code yet, but I think we could just treat this as a sometimes-available autofix for ANN201 and the other rules that check for return type annotations, rather than treating it as a separate rule.

[intgr]

haven't had a chance to review the code yet

Just be aware that it's very incomplete and broken right now.

we could just treat this as a sometimes-available autofix for ANN201 and the other rules that check for return type annotations, rather than treating it as a separate rule

I see where you're coming from. My initial thoughts:

• I imagine that this rule doesn't just add a hint, but can change a hint that it determines is incorrect. But it remains to be seen if this can be done reliably (#3704 is a counterexample).
• If we add several ways to infer return types, some of them more reliable than others, then by grouping them under one rule, users lose the ability to pick which ones they want and which they don't. But perhaps the distinction between safe/unsafe edits is sufficient here.

But I'm by no means committed to this approach.

[charliermarsh]

I ended up adding a similar fix for the ANN rules as a fun Sunday-night hack: #8643. It won't apply to functions that already have annotations as you mention, but the logic does extend to other primitive types and unions of those types.