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>
GitOrigin-RevId: 9f58961f9eb70e4f9dbba7359f5aafdfd392b7e2
Don't load more than 10 images per plugin. Some plugins have 50+ images which take 1Gb in heap and might cause OOM.
GitOrigin-RevId: 57e98c83028171f9bc53a86847de7d146ec3e059
PythonSdkFlavor#getName is expected to return the prefix of Sdk#getVersionString result,
which is normally an output of `/path/to/python -V` or a similar command
(see the implementation of PythonSdkFlavor.getLanguageLevelFromVersionString).
Since uv primarily manages CPython-based venvs, its getName() for them should
be "Python", not "Uv". PythonSdkFlavors for Pipenv, Poetry, and venv achieve that
by extending CPythonSdkFlavor.
Because an incorrect prefix was returned, we defaulted to LanguageLevel.getLatest()
that was then set for project files by PythonLanguageLevelPusher despite the right
version string recorded in SDK data.
However, one can also install pypy interpreters with uv. We should think of a way to
properly recognize their versions as well.
GitOrigin-RevId: c7331653c34fc5814d2de08318cd44462a96eace
I found a bug in TransformingIterator: hasNext isn't side-effect-free,
and because of that calling hasNext() twice skips two elements.
But then, I found that in comment in review IJ-MR-107533,
where the custom seq was implemented, it was said that
this seq is a temporary solution.
So, let's remove it then.
^KTIJ-32260
GitOrigin-RevId: 0679789333698ec3a994ab05bd9f62fb75c2bc49
The nested declarations are first converted to be effectively static if they capture an outer class.
^KTIJ-28862 fixed
GitOrigin-RevId: c035ba0350702f8934a1258b408521afc8736ea8
The IDE resolves build root by the defined working directory in the BuildEnvironment. We have two cases where working directory isn't a build root:
1. Working root corresponds to the Gradle subproject. In this case, we find the nearest parent directory with settings.gradle[.kts] file. This directory will be our build root.
2. Working root corresponds to the Gradle subproject in the included build. This case, also, can be divided by two cases:
* We execute a Gradle run configuration. In this case, we resolve the working root like as we do it in the first case.
* We execute a Gradle sync. In this case, we reuse the BuildEnvironment from a parent included build or project root build. Then we use it for the resolution from the first case. This case may happen only on the old Gradle versions, because the Gradle is newer than 8.0 can resolve all included builds inside the one Gradle model fetch request.
Issues IDEA-363359, IDEA-344664
GitOrigin-RevId: ccc73b78321d1a6983a897f34cfaff3493dd3e5b
The Gradle connection can be redefined during the Gradle sync. Therefore, the API cannot guarantee that connection is open in any sync moment.
Issues IDEA-363359, IDEA-344664
GitOrigin-RevId: bb42168971d564bb3fe427fa13d9b1f70782cb44
The complex ProjectConnectionDataNodeFunction can be replaced by the two simple functions that prepare Gradle connection and adds error handling for the Gradle sync execution
Issues IDEA-363359, IDEA-344664
GitOrigin-RevId: 1652df80f00e61d765db7c8a55f60931361d5318
The GradleExecutionHelper#execute function does not need to be overridden. Therefore, the GradleExecutionHelper class can be converted to the canonical utility class.
Issues IDEA-363359, IDEA-344664
GitOrigin-RevId: e79da247877fa953b776fbb6fc1f6140fb9608b5