Fix Not ImplementedError crash in meet.py for UnpackType

[jameslovespancakes]

Implements visit_unpack_type method in TypeMeetVisitor to handle type meets involving UnpackType. Previously raised NotImplementedError causing crashes when type-checking code combining ParamSpec and TypeVarTuple with Unpack.

Fixes #20093.

Changes

This PR implements the visit_unpack_type method in the TypeMeetVisitor class in mypy/meet.py. The method handles three cases:

1. Both types are UnpackType: Recursively computes the meet of their inner types and wraps the result in a new UnpackType
2. One is UnpackType, other is builtins.object: Returns the UnpackType as it's more specific
3. Otherwise: Falls back to default behavior (returns UninhabitedType)

This follows the same pattern used in subtypes.py for handling UnpackType comparisons.

Verification

The fix was tested with:

• The reproduction case from the original issue (no longer crashes, produces expected type error)
• All 213 existing unpack/vararg tests pass
• All 65 TypeVarTuple tests pass
• All 126 ParamSpec tests pass

Example

Before this fix, the following code caused an internal crash:

from typing import Callable, ParamSpec, TypeVar, TypeVarTuple, Unpack

P = ParamSpec("P")
T = TypeVar("T")
Ts = TypeVarTuple("Ts")

def call(func: Callable[P, T], *args: P.args, **kwargs: P.kwargs) -> T:
    return func(*args, **kwargs)

def run(func: Callable[[Unpack[Ts]], T], *args: Unpack[Ts], some_kwarg: str = "asdf") -> T:
    raise NotImplementedError

def foo() -> str:
    raise NotImplementedError

call(run, foo, some_kwarg="a")  # NotImplementedError crash

[A5rocks]

a) please add a test case
b) this solution doesn't make sense to me. I feel like we should prevent an unpack being met to begin with, but I'm not completely sure. Can you explain why we need to have the meet?

[jameslovespancakes]

Updated the fix based on feedback.

What changed: Instead of implementing visit_unpack_type() in meet.py, now using the existing safe_meet() function in typeops.py.

Why this is better: safe_meet() already handles UnpackType along with other variadic types and edge cases. It's a 1-line change vs implementing a new visitor method.

Testing: Added regression test in check-parameter-specification.test. All 394 related tests pass.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[A5rocks]

If safe_meet is enough, then this shouldn't be required?

[sterliakov]

Was this PR and its description generated by some AI/LLM tool?

I'm moderately certain that we should not implement meet(Unpack, X) for any X. I tried to take a look at this crash yesterday; there's quite a long inference chain: first (during the first inference pass), the ParamSpec heuristic below generates a callable of the shape def f(func: Callable[[], str], some_kwarg: Literal['a']?) from call-site kwargs. Note that some_kwarg is not kwonly there.

mypy/mypy/constraints.py

Lines 229 to 244 in f09aa57

	if param_spec and callee.arg_kinds[i] in (ARG_STAR, ARG_STAR2):
	# If actual arguments are mapped to ParamSpec type, we can't infer individual
	# constraints, instead store them and infer single constraint at the end.
	# It is impossible to map actual kind to formal kind, so use some heuristic.
	# This inference is used as a fallback, so relying on heuristic should be OK.
	if not incomplete_star_mapping:
	param_spec_arg_types.append(
	mapper.expand_actual_type(
	actual_arg_type, arg_kinds[actual], None, arg_kinds[actual]
	)
	)
	actual_kind = arg_kinds[actual]
	param_spec_arg_kinds.append(
	ARG_POS if actual_kind not in (ARG_STAR, ARG_STAR2) else actual_kind
	)
	param_spec_arg_names.append(arg_names[actual] if arg_names else None)

This is, however, not a bug itself: that heuristic generates P :> Parameters(...) constraint, so unconditionally converting call kwargs to kwonly parameters would be invalid. That's exactly the tradeoff made in #15896.

Then (second inference pass) we try to unify def run(func: Callable[[Unpack[Ts]], T], *args: Unpack[Ts], some_kwarg: str = "asdf") -> T against it. And this doesn't go so well: some_kwarg of f corresponds to Unpack[Ts] by position and some_kwarg by name, so we try to meet them. This looks like a bug to me, but meeting to Never (as safe_meet does) would not significantly improve the situation: the inference result will still be wrong.

So there are two problems: first, we try to unify the wrong function, and second, that wrong function crashes when unified. Addressing any of those issues will fix the crash, but not necessarily resolve the root problem.

(I don't think this can be merged, to be clear)

[jameslovespancakes]

No.

You're absolutely right - I can confirm that safe_meet() just masks the real bug rather than fixing it.

I traced through the inference and verified that:

1. The ParamSpec heuristic (line 241-242 in constraints.py) converts some_kwarg="a" to ARG_POS instead of ARG_NAMED
2. This creates an incorrect callable shape with 2 positional params instead of 1 positional + 1 keyword-only
3. The resulting type error message shows: expected "Callable[[Callable[[], str], str], str]"
   • The second "str" parameter is wrong - it should be keyword-only, not positional
4. safe_meet() prevents the crash by returning Never, but the inference result is still fundamentally incorrect

The real fix would need to address why the heuristic treats keyword arguments as positional, though I understand from PR #15896 that this is a deliberate tradeoff and not straightforward to fix.

I'll close this PR since it doesn't address the root cause.