After PY-55548 no need to change type hint `object` to `float`
(cherry picked from commit d9ba34fb955df644b7892b070dc1f5523db7fce9)
IJ-CR-152255
GitOrigin-RevId: ae0f12168de11265c14432709abb074d35530ccc
Also, silently returning from the function will leave the link non-working, what is confusing for the user
(cherry picked from commit 7b0384c5810ab38268420f172c7e3ddbef0d7b15)
IJ-CR-151630
GitOrigin-RevId: 15bdac04edde15e1b181e18d9006485c141b6308
* Fixed also the Python Console case: transposed 1-Dim table there as well
(cherry picked from commit a6c783dc38aa3c5050a836c36d8a76e8b3cbda19)
GitOrigin-RevId: b7fe92925fe8702ffd80e56a4fe0c313c6411372
* Transposed 1-D numpy array on the Python side of the Debugger
* Applied setMaxItemsForSizeCalculation method to the myRowHeader table to minimize calculations for getRowHeight
(cherry picked from commit f88fa625f2d8673cba2c9819f2907462b3f2301d)
GitOrigin-RevId: de6f919f18caec6624b1696790a88e10659e96f0
We might have scripts there (on Windows) like `fix_path.cmd`, we need to exclude them
(cherry picked from commit e09ceac554f456a3d8a931e0dfe26872908c303c)
IJ-CR-151567
(cherry picked from commit 8a8d68e41a6bd607622f3b6afa76e5dc878f4236)
IJ-CR-151953
GitOrigin-RevId: 9a463cdc1e0c348c2ffa27f26e64781f5014bd97
Add the new setting: create poetry env in the project.
Merge-request: IJ-MR-149143
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
(cherry picked from commit ed85efe339518cdf6949752be286172113931c22)
IJ-MR-149143
GitOrigin-RevId: 3a682aac846e4a80e8310a3dcc0a5f1c988d28e2
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
__anext__ method is required to return Awaitable. When getting iterated type, unwrap that awaitable
Merge-request: IJ-MR-150432
Merged-by: Aleksandr Govenko <aleksandr.govenko@jetbrains.com>
(cherry picked from commit 97a070ead70c0ec0f2da08000517c592c5805965)
IJ-MR-150432
GitOrigin-RevId: 21dc20b164e6095e56707ea50bc93bf67564e88e
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
FUS statistics consists of two parts:
1. Interpreter (i.e "venv" or "conda")
2. Project generator type ("Django" or "Flask")
`com.jetbrains.python.newProjectWizard.collector.PythonNewProjectWizardCollector.GENERATOR_FIELD` was a class without any limitation and `DirectoryProjectGenerator` instance was reported (i.e one for Django).
When migrated to NPW, we:
1. Dropped most old generator classes
2. Called this function providing `this::class` by accident, and it was `CoroutineScope`, so we finished with lots of `CoroutineScope` as generator type in FUS.
We must:
1. Provide old names for project types to preserve statistics.
2. Make it type-safe this time.
We also found that interpreter statistics is nullable for `PySdkCreator` which isn't true: SDK creation statistics is always not null.
So we:
* Introduce interface for project generators that reports "name for the statistics"
* Implement it both for DS and PyCharm by returning class name by default
* Overwrite it for several well-known generators to preserve statistics (use old named of now-deleted classes)
* Make interpreter statistics not null.
(cherry picked from commit bdfa73ba043d3584c6ba1871bca7a464a550bc21)
KT-CR-19191
GitOrigin-RevId: 53f874c18d67d33083cf8508a58be257b5e89ab7
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
Docstring rendering is no longer supported for Python 2, which became obsolete after reaching its end of life in 2020. Without updates or security patches, most tools, including documentation generators like Epydoc, have shifted focus exclusively to Python 3.
(cherry picked from commit ace78ac9ad943278449d5b20bb92db9f7571b5b5)
IJ-CR-148150
GitOrigin-RevId: 75cc87e05c61c3c17c26689552080e3c3082bfdc
`isValidSdkHome` works for local paths only.
We must use `sdkSeemsValid` instead: it is aware of remote interpreters and usually ignores them if can't validate
(cherry picked from commit 31b42e14518f5a8f7a69ba35e50353f4f4894f42)
IJ-CR-149658
GitOrigin-RevId: b30a6bb5d8a6b9986b0690eabbd0d39da6310f01
Also, don't query LanguageLevel for each element of each instruction,
only once per scope traversal.
This doesn't fix the problem with unreachable definition *inside* blocks under
unmatched version checks, i.e.
if sys.version_info < (3, 8):
Alias = int
expr: Alias # unresolved
but it's a more difficult problem how to handle those consistently with the idea
of unreachable version checks under the *current* interpreter version, and hopefully
it occurs rarer than, say, unresolved top-level imports of common names from typing.
(cherry picked from commit 55fd4597c6d0860d290caba15fbf4d313e985a86)
IJ-CR-149696
GitOrigin-RevId: 357ada7e10618aef75c470e6cd878f7672109e83
Because async generator methods in ABC and protocols are supposed to be declared as
plain "def" methods so as not to confuse type checkers with their AsyncIterable
return type annotations, it's better to disable such type-hint re-use if methods
async-ness don't match and not wrap anything in typing.Coroutine implicitly.
See also https://mypy.readthedocs.io/en/stable/more_types.html#asynchronous-iterators
(cherry picked from commit 6342f15a7786ec0d02ee1ab2b18fd40fd1ca1430)
IJ-CR-149694
GitOrigin-RevId: 3e19f190d9334e6c8648462ebb5b61abe931b0e6
