inconsistent-return-statements with assert False in function call

[douglas-raillard-arm]

Hello,

Steps to reproduce

def f(x):
    if x == 1:
        return 42
    assert False

Current behavior

example.py:2:0: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)

Expected behavior

No error. This is pretty similar to this issue #1782, except that assert False is being used. I can currently work around with something like raise RuntimeError('Unreachable') but assert False is a common idiom to mark unreachable paths, and should be pretty easy to match.

pylint --version output

pylint 2.6.0
astroid 2.4.2
Python 3.8.7 (default, Dec 24 2020, 17:53:09) 
[GCC 10.2.0]

[PCManticore]

While this might be a false positive, do note that the assert False might be stripped if you are running Python with -O, in which case an exception might be the best solution for asserting that a code path is never reached.

[douglas-raillard-arm]

Sure, I'm not trying to catch AssertionError anywhere so I don't rely on the exception actually being raised, this is only a safety check in case some other bug means this line ends up being executed, as well as some sort of enforced documentation.

From static analysis point of view, this is a good way to allow the user to pass extra knowledge on the data and control flow in cases that would be almost impossible to guess for the tool. For example, I've seen assembly code generation changes with GCC when using some assert() to add properties about a value (something like unrolling a loop when the induction variable is bounded with a small enough constant or something like that).