Only consider meta variables in ambiguous "any of" constraints

[sterliakov]

Sometimes our constraints builder needs to express "at least one of these constraints must be true". Sometimes it's trivial, but sometimes they have nothing in common - in that case we fall back to forgetting all of them and (usually) inferring Never.

This PR extends the fallback handling logic by one more rule: before giving up, we try restricting the constraints to meta variables only. This means that when we try to express T :> str || U :> str in the following setup:

from typing import TypeVar

T = TypeVar("T")
U = TypeVar("U")

class Foo(Generic[T]):
    def func(self, arg: T | U) -> None: ...

we won't ignore both and fall back to Never but will pick U :> str instead. The reason for this heuristic is that function-scoped typevars are definitely something we're trying to infer, while everything else is usually out of our control, any other type variable should stay intact.

There are other places where constraint builder may emit restrictions on type variables it does not control, handling them consistently everywhere is left as an exercise to the reader.

This isn't safe in general case - it might be that another typevar satisfies the constraints but the chosen one doesn't. However, this shouldn't make any existing inference worse: if we used to infer Never and it worked, then anything else should almost definitely work as well.

See the added testcase for motivation: currently mypy fails to handle Mapping.get with default without return type context when Mapping has a type variable as the second argument. https://mypy-play.net/?mypy=1.15.0&python=3.12&flags=strict&gist=2f9493548082e66b77750655d3a90218

This is a prerequisite of #18976 - that inference change makes the problem solved here occur more often.

[sterliakov]

@ilevkivskyi I understand no one wants to touch this inference logic to avoid regressions, but I think I found a very nice improvement in #18976 that closes a bunch of issues with a commonly used idiom, and this is the only prerequisite to fix one major regression caused by that. Could you have a look and say whether this idea makes sense at all?

[ilevkivskyi]

Hm, although the general idea is correct (and moreover unfortunately there are places scattered around the code where we treat unrelated type variables incorrectly), I think the implementation may be simplified. Instead of what you are doing, can you try to filter away type variables that are not meta vars? I.e, try simply

[c for c in option if c.type_var.id.is_meta_var()]

as a fallback (you may need to handle cases when this returns all and/or none of the constraints).

[sterliakov]

...I'm feeling dumb now, I swear that was my very first attempt! This works and is definitely saner - perhaps I missed the empty result case initially.

Yes, I do see that non-meta typevars are mishandled here, but probably don't have enough energy to fix that.

[github-actions]

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

[sterliakov]

It didn't cause any primer regressions, the issues check is also clean (sterliakov/mypy-issues#32 - two changed issues; both improvements, but insufficient to consider them resolved). @ilevkivskyi ready for another round!

[ilevkivskyi]

LG, thanks, just some minor suggestions.

[ilevkivskyi]

Please add a reveal_type(ok1) here.

[ilevkivskyi]

Suggested change

	# Try harder: if that didn't work, try to strip typevars that aren't meta vars.
	# Try harder: if that didn't work, try to strip typevars that aren't meta vars.
	# Note this is what we would always do, but unfortunately some callers may not
	# set the meta var status correctly (for historical reasons), so we use this as
	# a fallback only.