Check implicit None return is valid when using --no-warn-no-return

[hauntsaninja]

Fixes #7511

[ofek]

Awesome!

[sobolevn]

Can you please add some docs please? Because it is not clear to me how this works. I assume it is an opposite of --warn-no-return, but not like a "full" opposite, but a partial one for an implicit None return? Kinda?

Anyway, it looks like a lot of people are happy about it 🙂

[sobolevn]

What will happen for a case like:

def implicit_optional_no_return() -> Optional[int]:
    print(1)  # or any other non-primitive body

[sobolevn]

And what will happen for just -> int?

[hauntsaninja]

No error for the first, error for the second Incompatible return value type (implicitly returns "None", expected "int"). Same as the existing test cases, since the if statement has no impact on reachability.

[sobolevn]

Do we need test cases for ... and pass?

[hauntsaninja]

There's no change of behaviour here, so covered by existing tests. (Also note that every test would complain about errors in stubs if the trivial body logic breaks — I know because I broke this locally initially)

[hauntsaninja]

No, it continues to be a full opposite of --warn-no-return, but we just fix some unsoundness (so no docs change needed).

I suspect this got overlooked because the old behaviour was written back when --no-strict-optional was the default and the old behaviour is sound with --no-strict-optional. I added test cases with and without --strict-optional :-)

[hauntsaninja]

Because it is not clear to me how this works.

The new error generated isn't really anything to do with explicit returns or implicit returns, it's just type checking the logic of the function per Python semantics.

To take your example from #13203 (comment)
On mypy's normal settings, these both error with "Missing return statement", which is great, but slightly opinionated.

def func_one(self) -> int:
        self.x += 1

def func_two(self) -> Optional[int]:
        self.x += 1

Previously, when using --no-warn-no-return, neither of these would complain. But that's unsound for func_one since it promises that it can never return None; with this PR you get Incompatible return value type (implicitly returns "None", expected "int")

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉