Flatten TypeAliasType when it is aliased as a Union

[TH3CHARLie]

Resolves #8125

@appleby has some really good thoughts on the issue and I tried some of them.

The main problem is not about flattening unions inside variants since the following code generates no error

from typing import Union

T1 = Union[int, float]
T2 = Union[Union[Union[int, float], float], Union[float, complex], complex]

def foo(a: T2, b: T2) -> T2:
    return a + b

The problem, however, is because when using TypeAliasType to alias a Union, the TypeAliasType will not get flattened, so this PR fixes this.

I haven't added testcase yet, since no proper fixture file seems to support the add ops in the test code of #8125 , so lots of error: Unsupported left operand type for + will be reported (running mypy using command line will pass the test code)

• add testcase

cc @msullivan

[appleby]

IIUC, this change only handles a single level of nesting? A single level is all I currently need so I'm not complaining, but, for example, the following still fails to typecheck for me.

from typing import Union

T1 = int
T2 = Union[T1, float]
T3 = Union[T2, complex]
T4 = Union[T3, int]

def foo(a: T4, b: T4) -> T4:
    return a + b

[TH3CHARLie]

IIUC, this change only handles a single level of nesting? A single level is all I currently need so I'm not complaining, but, for example, the following still fails to typecheck for me.

from typing import Union

T1 = int
T2 = Union[T1, float]
T3 = Union[T2, complex]
T4 = Union[T3, int]

def foo(a: T4, b: T4) -> T4:
    return a + b

Yeah you're right, I'll fix it up
I've patched it up in 0a12cfd. Notice that flatten_nested_unions is already used for UnionType.__init__, in order to prevent a double-flatten, I add a boolean flag to control this and therefore breaks no backward compilability.

[appleby]

I can't comment on the suitability of the fix, but I can confirm that the changes here resolve both the toy minimal example in #8125, and also the Real World type checking issue I was having that prompted me to open #8125 in the first place.

[ilevkivskyi]

Thanks! This fix looks reasonable to me (at least for now). I previously mentioned potential of such problems because of the new type alias representation. Maybe at some point I will run a session of "fuzzy testing": will run all tests where unions are randomly replaced with nested aliased unions.

Please add tests and I think I will merge this.