Enhance null safety for project path names in dialog titles and UI elements. Adjust logic to handle cases where parent folders or file names are missing, ensuring better user experience and preventing potential null pointer exceptions.
(cherry picked from commit 9c37e2d41b113e42ee4f11efb4097f20cb1faf85)
# Conflicts:
# community/platform/platform-impl/src/com/intellij/ide/trustedProjects/TrustedProjectStartupDialog.kt
GitOrigin-RevId: 6ab20958aecbf89f6351ec9ad0b3022067146220
The OOM already happened and current dump won't help to detect what was wrong.
Yet, it creates "empty" reports and takes user time to collect snapshot, restart IDE and send the report.
(cherry picked from commit 862e560a4a337e56ba4ca7f7467cae5db30d9a8b)
IJ-CR-151911
GitOrigin-RevId: 91735559c7e21b371171bc789e4db0b0449e6c9d
* 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
WSL v1 is still not supported. However, there is a notification suggesting a hack.
Previously, no notification was shown and git was detected on a host machine producing
"detected dubious ownership" errors.
Also introduced `UnsupportedWSLVersionException` preventing potential miss-leading
notifications in `WindowsExecutableProblemHandler` and hide VCS widget for the
unsupported WSL case.
(cherry picked from commit 9f86bd101b0d2612e116933d2ef086c4b7ae8148)
IJ-MR-151925
GitOrigin-RevId: 5ae4e5711900c7c14f1688f26b245b0f6ddb380f
Locking in `java.lang.Deprecated` also led to locking out `kotlin.Deprecated`
alternative symbol.
This, in turn, led to adding explicit imports for everything from `kotlin.*`
package.
This seems like a wrong logic, but this will be dealt with later,
probably as a part of KTIJ-32231.
The current solution is to not lock out the `kotlin.Deprecated`
symbol for `KtUserType` positions (it includes annotation calls).
This logic is already present in K1 Mode's `OptimizedImportsBuilder`.
Also, add a muted testcase for KTIJ-32231 (doesn't work in both K1 and K2)
Also, add muting logic to the K1's `AbstractOptimizeImportsTest`
^KTIJ-32202 Fixed
(cherry picked from commit 89ce6287a44bd05b55cc6bbb3b01157bee30b41c)
IJ-CR-150012
GitOrigin-RevId: e4d004a7a10631afca474330c966a9332933d3da
Better naming, get rid of redundant nullable lists early
(cherry picked from commit 6cbaaee13a290500d7fbdc7d96fdd2946723cb05)
IJ-CR-150012
GitOrigin-RevId: 20c92c10aafd73ee0c65c662f49b51760f358489
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
If the project has 2+ JDKs, it's possible that we want to use an annotation from another module, which uses another JDK, so we won't be able to find it if we search inheritors of java.lang.Annotation defined in our JDK only
Fixes IDEA-362050 Annotation auto-complete is broken for some classes from other modules
(cherry picked from commit 3133dce302d9dfd03e169678c00fb4d0e23dd50b)
IJ-CR-151470
GitOrigin-RevId: 9f67471bcb07f2da5717414466832c5630414fd2
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
GrazieInspection can run in dumb mode after implementation of IJPL-155874.
But unfortunately, one of its filters (CommentProblemFilter) needs indexes.
So in some situations IDE gets stuck.
The easy solution is just to avoid checks requiring indexes.
A better solution would be to detect todo comments without indexes IDEA-364846.
(cherry picked from commit bc8962287f61eade48df703b7fa25dbd78fb83aa)
IJ-CR-151765
GitOrigin-RevId: 41df36e2ee169afedd2667c923afb36f932e6685
__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
In r1359167 Google introduced a breaking change: the type of the `Debugger.scriptParsed.debugSymbol` field was changed from `Debugger.DebugSymbols` to `array[Debugger.DebugSymbols]`.
To provide backward compatibility with old browsers, this fix introduces a new reader method `readObjectArrayOrSingleObject` which used if some object property marked with `JsonArray` annotation.
(cherry picked from commit 7847455a7c59cf7c7af3de9b991f2b6ca51928e7)
IJ-CR-150473
GitOrigin-RevId: ae6d2a42490bdcbf867d2727ce8207695d6ee3c5
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
It is better to be more explicit there, both for the sake of readability,
and to ensure safe evolution of the implementation.
Follow-up: IJ-CR-151167 IJPL-173167: RegionUrlMapper: Add async `tryMapUrl()`, migrate most of the usages
(cherry picked from commit fbeba1c512b23975f8676b2def05c6c863f2c835)
IJ-CR-151167
GitOrigin-RevId: e246a05f9efa16ed2b45120645947d62962b2605
Expose a public method `loadMapping()` that allows for proper error propagation.
(cherry picked from commit a0a6f6492773d5f4384ded84a6d0309c017f5fe6)
IJ-CR-151167
GitOrigin-RevId: c9f6a84c74a261369ce585fa14e6a5b156e12842
