Distinguish redundant-expr warnings from unreachable warnings

[llchan]

There are redundant expression warnings such as "Left operand of 'or' is always false" and "Left operand of 'and' is always true" that are previously categorized as unreachable. This is a bit of a miscategorization because in these cases all parts of the expression are still evaluated at runtime, compared to situations when the opposite condition is true and the right operand is short-circuited away (which is a stronger hint that something is wrong).

This PR introduces a new redundant-expr code and splits the redudant-but-not-short-circuiting cases out from the unreachable code.

Fixes #8711

[llchan]

Note to reviewer: I'm not familiar with the mypyc/dmypy side of things, so if any corresponding changes need to happen there let me know.

[JukkaL]

Thanks for the PR!

Since we already have lots of command line flags, are okay with waiting until #8975 has been implemented (#9172 is the PR) and then making the new error code disabled by default, instead of using a command-line flag? Our longer-term plan is to remove several of the existing command-line flags and to use error codes that can be individually disabled and enabled instead.

[llchan]

Sure, can wait on it. I'll subscribe to that PR, but if I overlook the notification feel free to ping me here.

[llchan]

@JukkaL I've rebased off master and updated this to use the new --enable-error-code functionality

[JukkaL]

Thanks for the updates! This is almost ready, just a few remaining comments.

Also, it would be good to document the new error code, as otherwise it won't be easily discoverable.

[llchan]

Done

[llchan]

@JukkaL + maintainers: anything else you need from me here?

[gvanrossum]

Mostly time to get to this. I’m not likely the best reviewer myself.-- --Guido (mobile)

[gvanrossum]

LGTM, two minor nits.

IIRC Jukka asked for documentation; I don’t see any documentation diffs in your PR. How/where are the error codes documented?

[gvanrossum]

Do you understand what this comment refers to? I wonder if the two nearly-identical comment blocks shouldn’t be refactored (the second could just say “similar as above comment”).

[llchan]

I don't know what exactly that comment means. When I split the conditions into two, I erred on the side of "explicit is better than implicit" and made sure the comment was copied to both places, so that a future change doesnt inadvertently lead to a dangling comment reference.

[gvanrossum]

(OT) Hey @llchan, would you be interested in taking a crack at #9054 ?

[gvanrossum]

Okay, let's leave that comment as is then. But what about documentation?

[llchan]

(OT) Hey @llchan, would you be interested in taking a crack at #9054 ?

Is that related to this PR somehow, or are you asking for general help? To be quite honest I'm not sure I'm familiar enough with the mypy internals to fix that in a time-efficient way (this PR was a little more straightforward since I was taking an existing error code and splitting it into two). I can experiment with it, since I'm sure we will hit that at some point now that we're using 3.8, but it may be better to assign it to an expert.

[llchan]

Documentation coming in the next push, working on it now

[gvanrossum]

(OT) Hey @llchan, would you be interested in taking a crack at #9054 ?

Is that related to this PR somehow, or are you asking for general help? To be quite honest I'm not sure I'm familiar enough with the mypy internals to fix that in a time-efficient way (this PR was a little more straightforward since I was taking an existing error code and splitting it into two). I can experiment with it, since I'm sure we will hit that at some point now that we're using 3.8, but it may be better to assign it to an expert.

It's only related to this PR because the problem is (likely) in the same area of mypy, and I believe you have shown that you know your way around that part. But if you feel that you're not up to it that's totally fine!

[gvanrossum]

LGTM. Thanks!