`no-matching-overload` related to nested type aliases after upgrading to 0.54.0

[jorenham]

This one involves 57 overloads, so so buckle up 😅

In scipy-stubs, two of the type-tests for scipy.sparse.block_array (src) started failing after upgrading Pyrefly to 0.54.0:

assert_type(sparse.block_array([[coo_arr, None]], format="bsr", dtype="float"), sparse.bsr_array[np.float64])
assert_type(sparse.block_array([[dia_arr], [None]], format="dok", dtype=complex), sparse.dok_array[np.complex128])

(src)

These first of these two tests targets the 26th overload (src):

def block_array(blocks: _ToBlocksUnkown, *, format: _FmtBSR, dtype: onp.AnyFloat64DType) -> bsr_array[np.float64]: ...

Here, _FmtBSR = Literal["bsr"] and onp.AnyFloat64DType is a union containing Literal["float"], so those two aren't the issue here, and the problematic bit seems to be blocks: _ToBlocksUnkown. This _ToBlocksUnknown type is an alias defined as follows (src):

_ToBlocks: TypeAlias = Seq[Seq[_T | None]]
_ToBlocksSpArray: TypeAlias = _ToBlocks[_SpArray2D[_SCT]]
_ToBlocksCanStackAs: TypeAlias = _ToBlocks[_CanStackAs[_SCT, _T]]
_ToBlocksUnkown: TypeAlias = _ToBlocksSpArray[_Numeric] | onp.ArrayND[np.object_]

The onp.ArrayND bit boils down to np.ndarray[something], and _ToBlocksSpArray[_Numeric] should reduce to Seq[Seq[_SpArray2D[_Numeric] | None]]. However, reveal_type(_ToBlocksUnknown) is reported by Pyrefly as

revealed type: TypeAlias[_ToBlocksUnkown, type[Sequence[Sequence[_T | None]] | ndarray[tuple[Any, ...], dtype[object_]]]]

This doesn't look right to me for at least three reasons:

• There a type on the first union variant, but not on the second, even though there's no type in the definiens.
• The _SpArray2D[_Numeric] disappeared
• There's a _T that's not in _ToBlocksUnkown.

So I'm guessing that there's a bugger in Pyrefly's nested TypeAlias unfolding logic.

See scipy/scipy-stubs#1291 for the full errors

[jorenham]

thanks @rchen152