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
We now allow spaces in project path (`validatePath`) but convert them to underlines for `projectName` (both changes are in `ProjectPathFlows`).
(cherry picked from commit cc875f7b4e6d2354fba79387a0fc9161a6d267e1)
GitOrigin-RevId: 620e5bca8a406c9588f3e4f54260e5e3162bf686
`versionString` might be `null` if python in severe broken.
Such pythons shouldn't be here, and we will fix it as soon as we introduce PythonInterpreterService
(cherry picked from commit d4658e07833d6f886991e794f90e5a16f28e50c3)
IJ-CR-150093
GitOrigin-RevId: e0fe53bdacbd014afa67115c9c9414a0cba9ba59
Assume we have the following sequence of events:
1. SDK list is empty
2. `setItems` gets called
3. SDK list set its status to "busy"
4. It gets filled with interpreters and first one is chosen
5. "Busy" flag is removed
For validation, we used to check "Busy" flag only: when it was "busy" we disabled "OK" button.
But before step 3 it isn't busy nor it has interpreter set. Clicking "OK" at this moment might lead to NPE (see the issue).
We now check if value is set fore validation.
(cherry picked from commit 99554914cb7dc67158828559ba2e6da81fdfe350)
IJ-CR-149868
GitOrigin-RevId: d50ffa6025238d515fc387c562f15f370ba1278c
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