Support stringified type annotations that span across multiple lines

[yilei]

Is your feature request related to a problem? Please describe.

Given the following code:

def something(
    arg,
) -> (
    "VeryLongClassNameWithAwkwardGenericSubtype[int] |"
    "VeryLongClassNameWithAwkwardGenericSubtype[str]"
):
    ...

Currently pyright won't accept it since the return stringified type annotation spans across multiple lines.

Describe the solution you'd like

It should support it and treat it the same as regular implicitly concatenated strings.

Additional context

This is discovered as part of psf/black#3462, Black can reflow the strings (merge implicitly concatenated strings into one when fits, or split them into multiple lines when it exceeds line length). I checked other type checkers (mypy, pytype, pyre), they do support it. But since pyright doesn't, psf/black#3462 special cases string annotations for all.

[erictraut]

There are good reasons why pyright does not support this. Unlike other type checkers, pyright is the basis for a language server, and it needs to be able to report accurate ranges for errors so they are underlined correctly. When it parses a stringified type annotation, it must parse the the entire string as a single block of text so any errors can be mapped back to the offset within the string.

For that reason, we have no plans to support strings that are concatenated string literals in type annotations.

If you need a type annotation to span multiple lines, you could use a multi-line string, like this:

    """(VeryLongClassNameWithAwkwardGenericSubtype[int] |
    VeryLongClassNameWithAwkwardGenericSubtype[str])"""

Another option is to use a typing.Union, like this:

    Union[
        "VeryLongClassNameWithAwkwardGenericSubtype[int]",
        "VeryLongClassNameWithAwkwardGenericSubtype[str])"
    ]

Or you can use from __future__ import annotations at the top of the file to eliminate the need for stringified types in type annotations.