Revert the revert of test changes that are not directly related to strict unions.
(cherry picked from commit 8a76bd91e040ad97e8ed680161f28370c84920f8)
IJ-MR-184619
GitOrigin-RevId: 4c293de3ecc3c8cb16869532fccc639e8c5a17ae
Because UnsafeUnion is not denotable, we used to generate Any in such cases.
(cherry picked from commit 2c43848c86ccbab416bd321aee2f999f61eda756)
IJ-MR-184619
GitOrigin-RevId: 1f086ddc0e83b26e371cc3a3b64407e1508d57e2
Namely, `generics_basic.py` in the conformance test suite and
Py3TypeCheckerInspectionTest.testTypeVarWidening.
Revert 07803c6243370d55df0d870e2e32b38170c1fb49
(cherry picked from commit 9c334ef32597be1d1e8fbc3251ac267be46555c8)
IJ-MR-184619
GitOrigin-RevId: 4b2440c973d9c7a7a42590665bd473c4e7a4c9cf
`testBreakInFinallyBlock` and `testReturnInFinallyBlock`
were testing vs. latest language level, so apart from
the compatibility warning (for which these tests are
intended) - a corresponding syntax error was captured
I made these tests to use a specific language level
so they only verify the correctness of the compatibility
inspection and introduced four tests in `PythonHighlightingTest`
to capture the syntax error
(cherry picked from commit 254570dc4d5022176590377eaf8ea6a08917937a)
IJ-MR-182362
GitOrigin-RevId: fb9c92923820b370672451c5753ee24bdd5a4570
It correctly takes into account the first argument of `__new__` that is also implicit,
and thus should be excluded when reporting positional-only parameters following
non-positional-only ones.
(cherry picked from commit abf09c6be5e49c21c12264d22bf63a51018fdcd6)
IJ-MR-180323
GitOrigin-RevId: 85fb7ea284a237252e8634344b968981eda56dc3
Both mypy and pyright don't show an error for the following case
@dataclass(frozen=False)
class Concrete4_Good7:
val1: Sequence[float] = [0]
However, according to spec, such mutable defaults are not allowed. It will also fail at runtime
(cherry picked from commit ee569653a8f5cf91d6cb87321d63bf8e208d172d)
IJ-MR-174248
GitOrigin-RevId: 275e527ac36ac727dfc23f17bd0b539cff9df8c2
Target expression should have either explicit `TypeAlias` annotation or valid type expression in assignment without type annotation (to be considered implicit type alias)
(cherry picked from commit 1059a8df2d221bd068eee706139be20c256df549)
GitOrigin-RevId: 8c952138fbc4124f02f717ce8a1784c1f0dc86b2
- support @dataclass(slots=True)
- add inspection for conflict with explicit __slots__
- add quickfix for new inspection
- add/adjust tests
GitOrigin-RevId: 5ac6efeb6c1e209b641365e2f22bdca74ae6484a
If a per-project ".venv" is not excluded, we consider
pythonX.Y/site-packages/typing_extensions.py a project source file,
giving it priority over the bundled typing_extensions.pyi in Typeshed.
In typing_extensions.py "Self" is defined as a function. Since we
special-cased PyTypingTypeProvider.OPAQUE_NAMES only for assignments,
we didn't recognize that it was a special form, and hence reported
it as referring to an illegal type hint.
Though it's more of an "incorrect project setup" type of problem,
I think it's still worth supporting functions as "opaque names"
just in case.
GitOrigin-RevId: 63f641cd8667fbb31ba1fb167a24ca825a8baf8b
Namely, that `Annotated` can contain arbitrary expressions and that `Literal` might
contain boolean and integer literals.
GitOrigin-RevId: 6b3d4212679d6556dfe1d4905f06a78e2769b4e2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Depending how the `Task` type actually resolves, Pycharm might see different qualified names.
In CPython, the concrete implementation of Task lives in the C accelerator module _asyncio (a binary module). The pure-Python asyncio.tasks.Task is effectively an alias to that implementation.
PyCharm builds “binary skeletons” for extension modules. When type inference resolves the class coming from your interpreter’s standard library, it often prefers those skeletons. As a result, the qualified name for Task is taken from the binary module where it’s actually defined: _asyncio.Task.
Typeshed stubs reflect this too (depending on Python version). They define/alias Task so that asyncio.tasks.Task, asyncio.Task, and _asyncio.Task can all refer to the same runtime class. Which one PyCharm reports as typeQName depends on how resolution landed: through the binary skeleton (_asyncio) vs the re-exported names in the asyncio package.
GitOrigin-RevId: ce6c27e33748a2b1a1b1ba725bccf3c44eaad782
- adjust parser to support comma separated list of error classes
- add problem annotation and quick fix for missing parentheses
- add new tests, adjust old tests
GitOrigin-RevId: a1b9bdf252ac874aa7bd1a6881c1784259bb35cc
Originally, when PY-62208 was first implemented, importable variants were always suggested
together with everything else, polluting the completion lookup with irrelevant "leaked"
top-level elements, such as loop variables, temporary variables, etc.
We first tried to exclude them by introducing this artificial threshold on "too short"
names that presumably could be typed manually and then imported with a quick fix.
It was possible to still complete them with a second invocation of the hotkey.
Eventually, we stopped offering importable variants at all if there are variants from
other completion contributors in PY-75580. In other words, they are suggested only when
a sufficiently long prefix has been typed to distinguish it from built-in symbols and
other names already available in scope.
Now it seems that this filtering on name length is redundant and often gets in the way,
preventing some common names, such as `Any`, `Enum` or `cast`, from being suggested.
GitOrigin-RevId: e10444d5bbbdde365f89aca38bb6f8f85940dd78
