New Tensorflow Typeshed has updated stubs for the keras module, as well as for other Tensorflow modules. So PY-65966 should not be reproducible anymore
(cherry picked from commit 929e1da40c82bf6dd26efd227c0421087df3b75c)
IJ-MR-157295
GitOrigin-RevId: 4bf2396c3cd62aea0339db51fbec058f1d765a05
PyKnownDecorator is now a class instead of an enum, allowing extension to create new instances
(cherry picked from commit 846617f68e559f7f77af15a999f837391ac3090e)
GitOrigin-RevId: f3a8d9ac39955c888647e7186ad4315305a380bb
Use a cache of reads to avoid processing all code paths in a nested function
twice when visitPyFunction is called separately for outer and inner function
definitions.
GitOrigin-RevId: b5e2640756893d7b87c8e4b2443927d012f645ad
The problem occurs when there are nested functions referring to variables
in the outer scope. The inspection implementation requires all nested scopes
to be visited to correctly detect unused local definitions, but the platform
may skip inner function when their enclosing function changes.
Unlike in PY-77891, the problem here is not the order of `visitPy*Element` calls
in the inspection visitor, but the fact that for some elements it's not invoked
at all.
Using runForWholeFile="true" forces full tree traversal and remedies the problem.
GitOrigin-RevId: 59ecba5ca204d51bba3e3b1b73c03f70bcbe231c
Fix build issues
Fix build issues
Remove redundant extension point
Fix build issues
Fix rebase issues
import rank
# Conflicts:
# .idea/libraries/jetbrains_ml_models_python_imports_ranking_model.xml
# .idea/libraries/jetbrains_mlapi_ml_feature_api.xml
# build/expected/ultimate-content-platform.yaml
# community/.idea/libraries/jetbrains_mlapi_ml_building_blocks.xml
# community/.idea/libraries/jetbrains_mlapi_ml_feature_api.xml
# community/platform/ml-api/intellij.platform.ml.iml
# community/platform/ml-impl/intellij.platform.ml.impl.iml
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/logs/fus/IntelliJFusEventRegister.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/logs/fus/eventFields.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/tools/logs/IntelliJFusEventRegister.kt
# community/platform/ml-impl/src/com/intellij/platform/ml/impl/tools/logs/eventFields.kt
# community/platform/ml-tools/src/com/intellij/platform/ml/tools/logs/fus/IntelliJFusEventRegister.kt
# community/platform/ml-tools/src/com/intellij/platform/ml/tools/logs/fus/eventFields.kt
# community/platform/platform-impl/codeinsight-inline/src/com/intellij/codeInsight/inline/completion/ml/TypingSpeedFeatureProvider.kt
# community/python/intellij.python.ml.features/src/com/intellij/python/ml/features/imports/README.md
# community/python/intellij.python.ml.features/src/com/intellij/python/ml/features/imports/mlModel.kt
# community/python/pluginCore/plugin-content.yaml
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlAnalysis.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlImplementation.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlLogs.kt
# community/python/src/com/jetbrains/python/codeInsight/imports/mlapi/mlTask.kt
Fix some tests
Refactor RelevanceEvaluationFeatures.kt to fix null handling
Improved the handling of `null` cases for `MODULE_SOURCE_TYPE` in `RelevanceEvaluationFeatures.kt`. This ensures more robust feature addition by checking conditions and setting the value accordingly when it's `null`. Minor formatting adjustments were also made.
Update ML model version in project configuration
Changed the Maven artifact ID from "lilac-coua" to "daffy-pony" for the python imports ranking ML model.
Fix some tests
Fix some tests
Fix some tests
Fix some tests
Fix some tests
Update Maven dependencies for JetBrains ML libraries
Update ML model version & fix missing read action
Update ML API version & update Imports Ranking implementation
Update mlapi version
Co-authored-by: Andrey Vokin <andrey.vokin@jetbrains.com>
Co-authored-by: Nikita Ermolenko <ermolenko.dev@gmail.com>
Merge-request: IJ-MR-147271
Merged-by: Gleb Marin <Gleb.Marin@jetbrains.com>
GitOrigin-RevId: 7aa520df915bb8a62263524868a17a984b619728
Alternatively, we can try to add a synthetic __dataclass_fields__
to all dataclasses with a PyClassMemberProvider.
GitOrigin-RevId: 98595a97138ba00ac95fff744b8f9cc1167c1ec4
Fix smoke tests
Update ML libraries
Remove kotlin std from classes of a library
Remove redundant extension point
import rank
PY-40997 Typing/Reformatting/Autocomplete lags when stubs for boto3 are installed
set test iteration count to 12
Co-authored-by: Gleb Marin <Gleb.Marin@jetbrains.com>
Merge-request: IJ-MR-150955
Merged-by: Gleb Marin <Gleb.Marin@jetbrains.com>
GitOrigin-RevId: 47140fd0301283a10966e14c65df9a08d128ec39
add new features: info about underscores in path, info about lib location, info about context of original file(extension type, psi parents, size of project),
info about already existing imports from the same library(in this file, in other opened files, in other files in the same directory)
GitOrigin-RevId: ca8206d4d7db6bc79e8f1a78502bf33696a653e9
`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
These changes make PyStatementList elements (which are function and class bodies, cycle bodies, if-else branches, etc.) lazy-parseable which means they can now be reparsed without reparsing the whole file if changes are happened inside them accepted as safe
The main reason behind these changes is to improve performance
GitOrigin-RevId: 892acbe0c95fde6aec74b7595b0a58f902c426f5
Otherwise, incomplete stubs break our custom logic for resolving tensorflow
modules re-exported from its _api.v2 subpackage, such as tensorflow.audio,
tensorflow.image, tensorflow.random, etc.
We did the same for Numpy stubs in the past, enabling them back once they
became mature enough.
GitOrigin-RevId: b1e46067406a592761f56b7d296a287e5282b079
Assume that such decorators as well as "well-known" decorators, which we special-case,
don't change signatures of decorated functions and classes.
This change effectively stops the long-standing policy of safe-listing a few recognized
"well-known" decorators and assuming everything else can change a definition in any
way. This approach doesn't apply well to the current state of the Python world, where most
of the common side effects of decorators, such as adding new parameters, can be expressed
in type hints.
In 2021.1 we added PyDecoratedFunctionTypeProvider that was able to infer a return type of
decorator over its body, as for any other function, and then correctly apply this information
to a decorated definition. It led to a number of problems.
First of all, depending on whether TypeEvalContext allowed us to access AST of a decorator's
body, we inferred different signatures for functions decorated with an imported decorator in
inspections and in user-initiated actions, such as Parameter Info.
Secondly, we started inferring useless `(*args, **kwargs)` signatures in case of decorators
defined following the common pattern of returning a wrapper function accepting arbitrary
parameters and itself decorated with @functools.wraps (PY-48338). In some sense, our code
analysis was "too smart" in its type inference in this case.
Lastly, we diluted the return types of functions decorated with unknown decorators, even
fully typed, by uniting these types with Any (so-called "weak" types). This logic
existed before PyDecoratedFunctionTypeProvider, but it became more problematic now
than we were able to propagate this artificial union through generic decorators.
This change in behavior might lead to some false positives for untyped Python code
with non-pure decorators. However, given that other type checkers are also likely to hit these
problems, there is now a stronger incentive to add type hints for such problematic APIs.
In the worst case, we can special-case some heavily requested decorators as we did before.
GitOrigin-RevId: db11fb3573bda5da155cb921a30adc31d5c841e2
Inspection covers such cases:
* Extending typing.Generic in new-style generic classes
* Extending parameterized typing.Protocol in new-style generic classes
* Using generic upper bounds and constraints with type parameters for ParamSpec and TypeVarTuple
* Mixing traditional and new-style type variables
* Using traditional type variables in new-style type aliases
GitOrigin-RevId: 8812959f64d2d87e1b72f713405edb86936220b9
Andrey Vokin
Mikhail Golubev
evgeny.bovykin
Aleksandr.Govenko
Alex Grönholm
Petr
Ilia.Kondakov
Daniil Kalinin
Vladimir Koshelev
Egor.Eliseev
Ilya.Kazakevich
andrey.matveev
Andrey.Matveev