Include tuple fallback in constraints built from tuple types

[sterliakov]

Fixes #19093.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

xarray (https://github.com/pydata/xarray)
+ xarray/conventions.py:413: error: Argument "decode_timedelta" to "decode_cf_variable" has incompatible type "object"; expected "bool | CFTimedeltaCoder | None"  [arg-type]

mongo-python-driver (https://github.com/mongodb/mongo-python-driver)
+ bson/__init__.py:1330: error: Unused "type: ignore" comment  [unused-ignore]
+ bson/__init__.py:1376: error: Unused "type: ignore[arg-type]" comment  [unused-ignore]

[A5rocks]

This makes sense. I think NamedTuples also use partial_fallback so can you add a test case using that?

[jorenham]

will this also stop mypy from crashing in case of a typo like this?

class MyTuple[*Ts](tuple[*_Ts]): ...  # oh no a typo

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/layers/google.python.pip/pip/lib/python3.12/site-packages/mypy/__main__.py", line 37, in <module>
    console_entry()
  File "/layers/google.python.pip/pip/lib/python3.12/site-packages/mypy/__main__.py", line 15, in console_entry
    main()
  File "mypy/main.py", line 119, in main
  File "mypy/main.py", line 203, in run_build
  File "mypy/build.py", line 191, in build
  File "mypy/build.py", line 267, in _build
  File "mypy/build.py", line 2937, in dispatch
  File "mypy/build.py", line 3335, in process_graph
  File "mypy/build.py", line 3430, in process_stale_scc
  File "mypy/semanal_main.py", line 97, in semantic_analysis_for_scc
  File "mypy/semanal.py", line 7621, in apply_semantic_analyzer_patches
  File "mypy/semanal.py", line 2587, in <lambda>
  File "mypy/semanal_shared.py", line 305, in calculate_tuple_fallback
NotImplementedError

https://mypy-play.net/?mypy=1.15.0&python=3.13&gist=1b2a9f33efc227902750f06f5b9c54e4

or should I open a new issue for this?

---

edit:

the same crash also seems to happen in case of valid code, btw:

class Shape0(tuple[*tuple[()]]): ...

https://mypy-play.net/?mypy=latest&python=3.13&gist=e201c77b05e55f03d4b475342475dd83

[jorenham]

And similarly, how about this one:

class Shape[*Ts](tuple[*Ts]): ...

reveal_type((42, ))         # tuple[Literal[42]?]
reveal_type(Shape((42, )))  # __main__.Shape[Unpack[builtins.tuple[Never, ...]]]

https://mypy-play.net/?mypy=1.15.0&python=3.13&gist=2e2ba990a2112c97ca8d9d071c559a56

is this also covered by this fix, or a different issue?

[sterliakov]

@jorenham No, this will definitely not fix a crash, and I highly recommend reporting that one separately ASAP as a crash (not a bug). I'll try to look into it when I have some time - that should be an easy fix.

The second snippet is also a different issue (probably unrelated to both this PR and the crash, please report too).

@A5rocks namedtuples are handled by a different branch and we should (hopefully) already have tests for that; constraints for namedtuples are built as if they were just their fallbacks, ignoring tuple items.

Any ideas what's that xarray primer hit? I saw it on several recent PRs (cf. #19102 that definitely cannot impact type inference), so probably not related to this change, but that's still curious.