Spurious error for code that fails truthy-bool even when not enabled

[huonw]

Bug Report

It seems that code failing to pass the truthy-bool check can have spurious errors that occur, even when that optional error code isn't enabled.

To Reproduce

https://mypy-play.net/?mypy=latest&python=3.12&gist=53000744586f03d23bb53f807d5a0ea0

class Truthy: 
    pass
    # def __bool__(self) -> bool: return True

def foo(truthies: list[Truthy]) -> None:
    sum(1 if x else 0 for x in truthies)

Expected Behavior

This code should typecheck fine: sum on ints is sensible!

Uncommenting the __bool__ definition (so that the truthy-bool error no longer applies, if it was enabled) passes type checking.

Actual Behavior

main.py:4: error: Generator has incompatible item type "int"; expected "bool"  [misc]

(Note that the truthy-bool error doesn't occur, as expected, because it isn't enabled.)

When running with that enabled one sees:

$ mypy testing.py --enable-error-code=truthy-bool
testing.py:7: error: Generator has incompatible item type "int"; expected "bool"  [misc]
testing.py:7: error: "x" has type "Truthy" which does not implement __bool__ or __len__ so it could always be true in boolean context  [truthy-bool]

Your Environment

• Mypy version used: 1.12.1
• Mypy command-line flags: N/A see playground
• Mypy configuration options from mypy.ini (and other config files): N/A see playground
• Python version used: 3.12

[huonw]

Ah okay, I did some hacking around (narrowed the problem down to Errors._filter_error and the ErrorWatchers, and so added unique stable index to each ErrorWatcher, and then binary-searched returning early from on_error for only specific instances (returning early stopped the bad behaviour), to find which exact one was of interest, and then printed the stack trace of its construction to find where).

This showed that the example in the description is caused by the hidden error interfering with return-type overload resolution:

mypy/mypy/checkexpr.py

Lines 2861 to 2873 in 94c49a8

	with self.msg.filter_errors() as w:
	with self.chk.local_type_map() as m:
	ret_type, infer_type = self.check_call(
	callee=typ,
	args=args,
	arg_kinds=arg_kinds,
	arg_names=arg_names,
	context=context,
	callable_name=callable_name,
	object_type=object_type,
	)
	is_match = not w.has_new_errors()
	if is_match:

In particular, it seems like an overload is rejected if there's any error, even if it's one like this that's not related to type-selection (per se), and even if the error is not emitted.

This happens in the Errors._filter_error call, that calls ErrorWatcher.on_error. The code above is creating the ErrorWatcher in self.msg.filter_errors().

mypy/mypy/errors.py

Lines 494 to 499 in 94c49a8

	# process the stack of ErrorWatchers before modifying any internal state
	# in case we need to filter out the error entirely
	# NB: we need to do this both here and in _add_error_info, otherwise we
	# might incorrectly update the sets of ignored or only_once messages
	if self._filter_error(file, info):
	return

Without knowing much about mypy, it seems like some errors should influence overload resolution, and other errors should not, and they should be distinguished, somehow.

This indicates to me that any error seems to be enough to cause problems, e.g. this code: https://mypy-play.net/?mypy=latest&python=3.12&gist=602669a7523d13f2bfc0191f48cd54e1

def foo(x: int) -> list[int]:
    return []
    
def bar() -> int:
    return sum(foo("x"))

main.py:5: error: Argument 1 to "sum" has incompatible type "list[int]"; expected "Iterable[bool]"  [arg-type]
main.py:5: error: Argument 1 to "foo" has incompatible type "str"; expected "int"  [arg-type]

The second error is correct (indeed "x" isn't valid to pass to foo), but the first is spurious: sum should work fine with list[int]. (This one isn't so bad, given it's an spurious error happening along with another real error.)

[huonw]

Ah, this looks to be the same cause as #17082, although the example in this issue is a more egregious instance, IMO.