Add no-any-return error code

[dillydill123]

Summary

Add an umbrella no-any-return error code that enables
no-any-return-implicit and no-any-return-explicit. These error codes
catch returning Any on a function that has a concrete type. The first,
no-any-return-explicit, will present itself in cases where an
explicitly typed Any is returned on a function that has a concrete
return type annotation. The latter, no-any-return-implicit, appears in
the case of an implicit Any, often coming from an another untyped
function.

Returning Any through a concrete return annotation weakens the guarantee
provided by the annotation. The caller sees a precise type while the
implementation has not demonstrated that the value satisfies that type.
Enabling these error codes will improve bug finding ability.

The strategy is to hook into where explicit return statements and
their expressions are processed and compare the return type to the
declared hint. This will be done for async and Generator functions
as well. yield from generators is explicitly not included in this
error code.

no-any-return is completely opt-in. The strict preset will not
include it by default. Migration from mypy's warn_return_any is
included in this change.

Fixes #3806

Test Plan

New unit tests added to cover this functionality.

No changes from test.py to commit.

[grievejia]

Thank you for the time and effort you put into submitting this!

Regarding error subcategories, our existing convention is to use suffixes for more granular error codes. For example, we could use no-any-return as the catch-all rule, alongside no-any-return-explicit and no-any-return-implicit. You can see this pattern already in use with existing codes like bad-override or inconsistent-overload.

As for the default severity, I am personally a bit hesitant to enable no-any-return by default, even in strict mode. My main concern is that if an upstream dependency intentionally returns Any, or if an upstream type error cascades into a returned Any, downstream users have no actionable way to address the error without intentionally subverting the type system (e.g., via cast or # type: ignore comments).

Emitting non-actionable diagnostics like this generally creates a very poor user experience. Because of this, I would prefer that this kind of error remains strictly opt-in, rather than being bundled into the default strict preset. (cc. @yangdanny97 for more opinions)

[dillydill123]

@grievejia Thanks for the review. Those changes are fine to me. Mypy enables no-any-return with strict, so this would be the only deviation. I would plan to make the following changes:

• Add catch all no-any-return which encompasses the no-any-return-explicit and no-any-return-implicit codes. Code names will be changed accordingly
• Remove no-any-return-implicit from implicit-any umbrella
• remove any return codes from strict, instead making 3 new opt in flags to enable them (one for catch all, one for explicit and one for implicit).

How does this plan sound? Do you prefer rebasing into one commit or shall I create a second commit with these changes?

[grievejia]

Sounds good! Perhaps we could enable it as well in our pyrefly init workflow from mypy. For Pyrefly by default, I'd propose we leave out of the strict preset. We can always come back and re-visit it in the future.

One minor clarification on step 3: you actually don't need to create any new dedicated configuration flags for these. Since we already have a generic mechanism for configuring individual error code severities,

Either having a second commit or doing single commit works for us.

[dillydill123]

@grievejia I've made the changes:

• Created no-any-return code and sub codes, which are completely opt-in; not part of any preset (besides all)
• Added migration from mypy's warn_return_any config option. Note that even though it says "warn", mypy does produce an error, not a warning.
• Updated PR Title, description and commit message.