Update test data.
1. Unresolved imports are not removed with optimize imports
2. Unresolved imports are not marked as unused
(cherry picked from commit 2c32c368ae0907fb75ea76fc9749e903c160667c)
IJ-CR-153189
GitOrigin-RevId: 153d42e7f61f8357eeb74f022e31bbe406e83c02
The logic for disabling the unused warning on unresolved imports was dependent on the visit order. Moving sustracting unresolved imports to the end of computation fixes the problem.
(cherry picked from commit adeb85e59c17261a5bf9f64dfb4a7836a2403f43)
IJ-CR-153189
GitOrigin-RevId: fac4173a0fac5b29be9301f9d5f04fed08cceff1
Add a processing function for new breakpoints.
Merge-request: IJ-MR-152628
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
(cherry picked from commit 63ebb4c7c620cf7cc3f56924619fc5adc09e25dd)
IJ-MR-152628
GitOrigin-RevId: 1f26240498360aff61ff27878118b0eb841ec082
Check YieldType of yield expressions in PyTypeCheckerInspection
Check that (Async)Generator is used in (async) function
Check that in 'yield from' sync Generator is used
Convert PyMakeFunctionReturnTypeQuickFix into PsiUpdateModCommandAction
Infer Generator type for lambdas
When getting function type from annotation, do not convert Generator to AsyncGenerator
Introduce GeneratorTypeDescriptor to simplify working with generator annotations
Merge-request: IJ-MR-146521
Merged-by: Aleksandr Govenko <aleksandr.govenko@jetbrains.com>
(cherry picked from commit b3b8182168c5224f0e03f54d443171ccf6ca7b89)
IJ-MR-146521
GitOrigin-RevId: a95670d7e2787015bcf162637ea6d7bfb47a312a
Updated PyFunction to account for implicit 'return None' statements when inferring return statement types.
It affected return type inference of PyFunction.
Fixed a failing test related to formatted strings.
Added a quick fix to make all return statements explicit.
Updated the CFG to include PyPassStatements, enabling detection of exit points in empty functions.
Simplified PyMakeFunctionReturnTypeQuickFix to independently infer function types and handle required imports. Currently, it does not support specifying custom suggested types.
Merge-request: IJ-MR-148719
Merged-by: Aleksandr Govenko <aleksandr.govenko@jetbrains.com>
(cherry picked from commit 9f58961f9eb70e4f9dbba7359f5aafdfd392b7e2)
IJ-MR-148719
GitOrigin-RevId: 68ef5c4a1cc0fcaffd750cc0713250a106136643
If there is an overload not followed by an implementation, which is
already an error, always resolve to the first overload, regardless
of whether it's a .py file, or a .pyi stub. It allows us to eliminate
the special RatedResolveResult#RATE_LIFTED_PY_FILE_OVERLOAD rate in .py
files, because we no longer need to duplicate the last, closest reachable
overload (normally an implementation should be reachable) with a higher
priority, and then filter it out during overload resolution.
Meanwhile, this filtering out didn't work right before
because some type inference logic, e.g., PyCallExpressionHelper.getCalleeType
used in PyReferenceExpressionImpl.getCallableType bypassed it. It should have
been done at the level of
PyCallExpressionHelper.forEveryScopeTakeOverloadsOtherwiseImplementations.
(cherry picked from commit 99a624ab85957d7a2d3c2c0ced596e472f9d615b)
IJ-MR-148398
GitOrigin-RevId: c2cdfe8c8b046118f4e6f7269dbf7848dd746e08
Previously, we mistakenly tried to resolve qualified names listed in the
`field_specifiers` argument of @dataclass_transform in the same scope
where the dataclass itself is defined, not where the actual decorator
application is located.
Thus, if in the file where the dataclass is defined, a field specifier
was imported differently than where @dataclass_transform was applied, we
couldn't recognize a field specifier call in the RHS of an assignment as such
and took it for an ordinary field default value.
In particular, this is what happened with pydantic dataclasses.
`pydantic.fields.Field` is usually imported as just `pydantic.Field` where
user dataclasses are defined, but imported with an alias and set in the
`field_specifiers` argument as `PydanticModelField` in
`pydantic._internal._model_construction` where `ModelMetaclass` is defined.
It was accidentally broken in f15a07836e7aeac7c46b489b4742e8248a0e6ef4 to
support decorating class methods with dataclass_transform
(see testData/inspections/PyDataclassInspection/DataclassTransformFieldsOrder/decorator.py).
Until PyResolveUtil.resolveQualifiedNameInScope automatically traverses through
containing scopes looking for a name, the file containing decorator application
seems like a safe trade-off for the scope, because field specifiers are normally
defined or imported somewhere at the top level.
(cherry picked from commit de9afeb0831a52f058453fe678de229d41c26a4d)
IJ-CR-151380
GitOrigin-RevId: b6576ec7b72ea1e19e93b6190372a5168003c396
Some dataclass implementations, such as Pydantic, allow declaring fields with
mutable defaults, deep-copying them under the hood.
See https://docs.pydantic.dev/latest/concepts/models/#fields-with-non-hashable-default-values
(cherry picked from commit e495621858950976226731dddbb01af4012704fa)
IJ-CR-151192
GitOrigin-RevId: 7412272584a4c26e404d3d84e6150f974027eca7
1. Fix the registration of the `PY_RETURN` signal. Stop unregistering the `PY_RETURN` signal for a `code: CodeType` after the first processing of `PY_RETURN`.
2. Fix the `LINE` callback during stepping and `SMART_STEP_INTO` commands.
3. Fix the `PY_RETURN` callback. Added handling for `SMART_STEP_INTO` and `STEP_RETURN` commands.
4. Fix the `_should_enable_line_events_for_code` function. Registration of the `PY_RETURN` and `LINE` signals for a `code: CodeType`.
Merge-request: IJ-MR-149452
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
(cherry picked from commit 8590efb7a1b2d8d6ca2393f18dcbca795e35d211)
IJ-MR-149452
GitOrigin-RevId: 4a157651e52072f3bdc186a61af7562e05a53da7
For async functions, unwrap return type from Awaitable or Coroutine
Merge-request: IJ-MR-146295
Merged-by: Aleksandr Govenko <aleksandr.govenko@jetbrains.com>
(cherry picked from commit 9fe8d02a9d8bb584b9d6972ce999912bd93875e6)
IJ-MR-146295
GitOrigin-RevId: 9bad4877a069268a2d0181cac70b9a0d399cb5e6
Previously, PyTypingTypeProvider.getReferenceType returned a type from a class attribute
type hint only for assignment to instance attribute located inside a class definition.
In other words, here we inferred the expected type from the annotation
and reported incompatible types in assignment:
```python
class C:
attr: int
def m(self):
self.attr = "foo"
```
but in the following we didn't:
```python
class C:
attr: int
inst = C()
inst.attr = "foo"
```
Now we try to resolve any qualified target expression to a class
or instance attribute and then infer the type from the corresponding
annotation.
(cherry picked from commit 086dbb678a8cd89cfe332bf801631568fb6c3a4d)
IJ-MR-147382
GitOrigin-RevId: 4e3f71baa598d4caf684d0aeab23d1a9a688b94d
Previously, we reported call arguments only if either all callee
candidates have unmatched arguments or all call candidates have
unmatched parameters. When there was a mix of the two, we reported
nothing.
(cherry picked from commit 97b42faf10de74ee7cd10f934d9eb94e1c8bbb34)
IJ-CR-146869
GitOrigin-RevId: 8babfe6a8ad0152f985655eff27df4df68936594
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
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
`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
As far as `__get__` call when accessing the attribute is implicit, create a synthetic call considering the type of callsite (access via instance or via class) and use its type as a type of property typed with descriptor class.
GitOrigin-RevId: acc36ebd2d62acfe99a5202b2478356f7b7aea46
In other words, this API allows inferring results of function calls based only on the type of reciever (e.g., class), if exists, and types of arguments passed to the function. The aim of this API is to replace the existing approach where we infer types of such "synthetic" calls by creating a new expression using `com.jetbrains.python.psi.PyUtil.createExpressionFromFragment` and then inferring the type of created expression
GitOrigin-RevId: 09bee7ba1757cb07910be245253fe4bd855f5076
