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
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
`PythonSdkUtil` duplicates VER logic. One Jython-specific thing was also removed as we do not need Jython anymore
GitOrigin-RevId: 658fc42b485ac074a6d89fce3c7408e51cdc8f95
`PythonSdkFlavor` detects pythons.
It uses `VirtualEnvReader` under the hood (see virtual env flavor) and system pythons (see other flavors).
We use it in `PythonLocalAddInterpreterModel` and cover it with tests
PY-74425 WIP, PY-74236: `VirtualEnvReader` shouldn't return `null` nor should it check for dir existence, use `getVEnvRootDir` as a default dir for venv.
The whole logic behind `VirtualEnvReader` is the following: we check for some env variable, and if it points to the correct path -- we use it. We fall back to the home directory otherwise.
Directory doesn't need to exist (hence, no need to check `isDirectory`) because a client might always create it.
Even worse: directory would probably not exist on a fresh OS, but a user still wants to create virtual envs there.
PY-74425 WIP: Encapsulate python names and patterns inside `VirtualEnvReader`.
`VirtualEnvReader` seems to be the main entry point to look for virtual envs on the local file system.
Historically, flavors did that, so they had a set of names and patterns to filter python by name, however:
1. `UnixPythonSdkFlavor` had named for **nix only, and `VirtualEnvSdkFlavor` had names both for Windows and **nix. It is unlikely to see a `.exe ` file on **nix or file, without an extension on Windows, so this check is useless and broken (`VirtualEnvSdkFlavor` checks for both names on both OSes)
2. `UnixPythonSdkFlavor` had regex to filter Python2, but this python was removed 4 years ago and could hardly be met on any new OS; hence this check is useless.
3. New Project Wizard needs to find pythons, but knows nothing about names and patterns.
Merge-request: IJ-MR-142040
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: ce649b4f12f7c7b60a25d8e1fb1222e075337844
