Reword the inspection text
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
(cherry picked from commit cab3cb1bbb1316462ee3fd37e735765b31b8d5e8)
GitOrigin-RevId: e3288e503d714a1f76bd1a2e6a0553770e1cbad5
* Remove unnecessary descriptor type inference from `PyTargetExpressionImpl.getType`
* Refactor overload resolution for synthetic calls, minor refactorings in PyDescriptorTypeUtil
* Add additional test for __set__
* Do not substitute missing argument types with implicit `Any` in PySyntheticCallHelper
* Always take the first overload for `__set__` if more than one is present
(cherry picked from commit 9d1f9d37f3ea23ce6145f82fc8f62212f744e858)
GitOrigin-RevId: 372dc0e8ccc32095aecf3f611645adc06c2873e9
Add API for inferring the expected type of `__set__` from `value` parameter
Add corresponding logic to PyTypeCheckerInspection to check if assigned value matches the expected descriptor type
Add tests on it
(cherry picked from commit b14ab7b2e40e225b508875a778ceae8986cbb291)
GitOrigin-RevId: 2b15b2b4527a95e5912897ba256dcc73d71c3dcd
Protected member should not be highlighted as a warning if it resolves to .pyi file.
We assume that everything in .pyi file is a public API.
GitOrigin-RevId: c8275f3e48e3cd69b1676de9b78606f28ea224c8
Sacrifice this old test for a good cause. The inferred type of `my_list_t1` is now `List[null]` which matches with pyright - it also has no complaints in the changed fragment
GitOrigin-RevId: 2176ffa69c6a24ec55344f4294e04542185ca7e7
Change the expected type of `testNewStyleTypeAliasOneWithoutDefault` test (now it is the same as in pyright)
Add the same tests but using old-style type aliases
Add a couple more tests on aliased types for some tricky cases
GitOrigin-RevId: 9d289d8e0964c592f4282f9970eeb9a08a8105e5
typing.Generic is a magical class that can be specified in any position
in the list of base classes, not affecting the MRO consistency. It's done by
the custom __mro_entries__ implementation in typing._BaseGenericAlias (Python < 3.12),
which skips this Generic entry if there are other generic classes following
it on the list of superclasses. Namely, it's possible to do the following:
```
class Base(Generic[T]):
pass
class MyClass(Generic[T], Base[T]):
pass
```
which would cause a TypeError for regular classes. Since it broke our implementation
of the C3 algorithm in PyClassImpl.getMROAncestorTypes, we now special-case it by
always moving typing.Generic to the very end of the base class list while constructing
MRO.
See https://github.com/python/cpython/blob/3.11/Lib/typing.py#L1298 for a pure-Python
version of typing._BaseGenericAlias.__mro_entries__ and a relevant discussion in
https://github.com/python/cpython/issues/106102.
GitOrigin-RevId: e7d765193d532ab8457133e8fb5ad06840d89225
Also fixes PY-59014, PY-39761.
PyResolveImportUtil returns both .pyi stubs and the corresponding .py files for stub packages
to support partial stub packages. See the line:
```
groupedResults.topResultIs(Priority.STUB_PACKAGE) -> firstResultWithFallback(groupedResults, Priority.STUB_PACKAGE)
```
in PyResolveImportUtil.filterTopPriorityResults.
It means that, for instance, resolving the QuerySet name in type hints led to QuerySet
definitions from both places. Then, PyTypingTypeProvider.getType() for the reference expression
"QuerySet" returned a union type containing PyClassTypes for both of them, we couldn't parameterize
it in PyTypingTypeProvider.getParameterizedType and returned Any.
It's wrong that while evaluating type hints, we interpret multiple declarations as
a union type. Those should only be explicitly expressed with typing.Union or "|" operator.
This behavior was originally added in PY-18427 as an ad-hoc way to support version checks
for type hints, but now it seems detrimental because it's unclear how to parameterize
such implicit unions of generic types then.
Other type checkers also don't treat conditional definitions like that. For instance, for
conditional type aliases, Mypy complains about the name being defined twice and then uses
only the first definition, and Pyright doesn't consider names under conditions other than
version checks as valid type aliases at all. Both type checkers also support partial stub
packages properly.
GitOrigin-RevId: 1ecc7ab5d09625d10850ddc0e1f7761332ccddd5
sys.version_info guards are processed at the level of ScopeImpl.collectDeclarations and
PyResolveUtil.scopeCrawlUp in PyReferenceImpl.resolveInner, as implemented in
3318ff79cdcc5ba0ce5e4feb65abad5ad0f4acfa.
However, once we collected all name definition candidates flow-insensitively this way, in
PyReferenceImpl.getResultsFromProcessor, if the reference and these candidates were located
in the same scope, we completely ignored these variants and gathered reachable definitions all
over again from CFG using PyDefUseUtil.getLatestDefs. And the latter didn't consider version
guards at all. I've added version guard checks directly in PyDefUseUtil.getLatestDefs.
GitOrigin-RevId: 9f92eecd1eb1812bfbd2bf54f8192f45f0cf0a1d
Namely, acknowledging them for import statements in df52f60574962e1bc222121aadc082683de0a869.
Additionally, the problematic conditional import of dict in csv.pyi as
```
if sys.version_info >= (3, 8):
from builtins import dict as _DictReadMapping
else:
from collections import OrderedDict as _DictReadMapping
```
was removed with the recent Typeshed update in 94973415b96b2a0f859d29b0201d1ccee0d06462 (PY-73263).
GitOrigin-RevId: 1100fd0dd01be9200149a1216b207bffa7ab13d6
In SDK:
* `v1`: legacy API that should be dropped (but still used by Python Plugin and DS)
* `v2`: slightly better API used both for new project and interpreter settings. Supports DSL UI validation. Must be adopted by DS and Python Plugin somehow.
In NPW:
* `newProject`, `newProject/steps` (aka `v1`) deprecated, used only by DS and Python Plugin.
* `newProjectWizard` (aka PyV3): the right new API to use. Sooner or later will be adopted by DS and Python Plugin
GitOrigin-RevId: c3d49ce95079dc5ba589955381ddfe42326295fd
`Application` isn't always available at that time. It is better to register allowed roots directly in the tests.
This reverts commit 8f8bf13f859e9cf69ab424b8692968a18aa537cc.
GitOrigin-RevId: c5cf6ba7fb77a7bc350b090a450519ecff1472ad
On TC you are only allowed to access certain directories (temp dir, project roots and so on).
Some services might also access Python interpreter folders (to index python libs for example), hence we allow this too to prevent exceptions
GitOrigin-RevId: 8f8bf13f859e9cf69ab424b8692968a18aa537cc
The refactoring also fixes the problem with wrong types inferred for contextlib.contextmanager
GitOrigin-RevId: 1601047786a0c43a463a82225b18635d407bcb40
`dataclass_transform` support posed a number of challenges to the current
AST/PSI stubs separation in our architecture. For the standard "dataclasses"
module and the "attrs" package API, we could rely on well-known names
and defaults to recognize and preserve the information about decorator
arguments and field specifier arguments in PSI stubs. With `dataclass_transform`
however, effectively any decorator call or extending any base class can indicate
using a "magical" API that should generate dataclass-like entities.
At the moment of building PSI stubs we can't be sure, because we can't leave
the boundaries of the current file to resolve these names and determine if these
decorators and base classes are decorated themselves with `dataclass_transform`.
To support that, we instead rely on well-known keyword argument names documented
in the spec, e.g. "kw_only" or "frozen". In other words, whenever we encounter
any decorator call or a superclass list with such keyword arguments, we generate
a `PyDataclassStub` stub for the corresponding class.
The same thing is happening with class attribute initializers, i.e. whenever
we see a function call with argument such as "default" or "kw_only" in their
RHS, we generate a `PyDataclassFieldStub` for the corresponding target expression.
Both of these stub interfaces now can contain null values for the corresponding
properties if they were not specified directly in the class definition.
Finally, for the `dataclass_transform` decorator itself, a new custom decorator stub
was introduced -- `PyDataclassTransformDecoratorStub`, it preserves its keyword
arguments, such as "keyword_only_default" or "frozen_default" controlling
the default properties of generated dataclasses.
Later, when we need concluded information about specific dataclass properties,
e.g. in `PyDataclassTypeProvider` to generate a constructor signature, or in
`PyDataclassInspection`, we try to "resolve" this incomplete information from stubs
into finalized `PyDataclassParameters` and `PyDataclassFieldParameters` that
contain non-null versions of the same fields. The main entry points for that
are `resolveDataclassParameters` and `resolveDataclassFieldParameters`.
These methods additionally handle the situations where decorators, superclass
lists and field specifiers lack any keyword arguments, and thus, there were no
automatically created custom stubs for them.
All the existing usages of `PyDataclassStub` and `PyDataclassFieldStub`
were updated to operate on `PyDataclassParameters` and `PyDataclassFieldParameters`
instead.
Counterparts of the tests on various inspection checks for the standard dataclasses
definitions were added for dataclasses created with `dataclass_transform`, even
though the spec is unclear on some aspects the expected type checker semantics, e.g.
if combining "eq=False" and "order=True" or specifying both "default" and
"default_factory" for a field should be reported.
I tried to follow common sense when enabling existing checks for such arbitrary
user-defined dataclass APIs.
GitOrigin-RevId: 4180a1e32b5e4025fc4e3ed49bb8d67af0d60e66
- PEP-696 adds a new syntax for declaring the default types of Type Parameters in new-new style generic classes, functions and type alias statements. Support these grammar changes.
- Store info about default types in stubs for Type Parameters
- Increment the stub version counter in PyFileElementType
GitOrigin-RevId: b6b22e3eaa86ce06132885781e5775a89bf4b840
