[red-knot] Fix bug where union of two iterable types was not recognised as iterable

[AlexWaygood]

Fixes #13990. My favourite kind of bugfix: more accuracy for less code!

[github-actions]

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check encountered linter errors. (no lint changes; 1 project error)

pandas-dev/pandas (+0 -0 violations, +0 -0 fixes)

pypa/setuptools (error)

ruff failed
  Cause: Failed to parse /home/runner/work/ruff/ruff/checkouts/pypa:setuptools/ruff.toml
  Cause: TOML parse error at line 1, column 11
  |
1 | include = "pyproject.toml"
  |           ^^^^^^^^^^^^^^^^
invalid type: string "pyproject.toml", expected a sequence

Linter (preview)

ℹ️ ecosystem check encountered linter errors. (no lint changes; 1 project error)

pypa/setuptools (error)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview

ruff failed
  Cause: Failed to parse /home/runner/work/ruff/ruff/checkouts/pypa:setuptools/ruff.toml
  Cause: TOML parse error at line 1, column 11
  |
1 | include = "pyproject.toml"
  |           ^^^^^^^^^^^^^^^^
invalid type: string "pyproject.toml", expected a sequence

[MichaReiser]

It would be nice to also have a test where one type is iterable and the other is not. E.g. iterator over str | int.

This should work as expected today but I think the fix you pushed now would have regressed the diagnostic precision when our errors distinguish between a non-iterable and an iterator missing the __next__ method.

[AlexWaygood]

This should work as expected today

in fact, it does not... great catch!

[carljm]

in fact, it does not

Should we capture this in an issue?

[AlexWaygood]

in fact, it does not

Should we capture this in an issue?

I am working on a fix. But if I do not succeed in putting up the fix, I will write up an issue.