_T_co in itertools.product declaration in Typeshed used to be imported from
_typeshed/__init__.pyi stub and was not resolved as a name starting with
an underscore. Nonetheless, its method __next__ was still recognized as generic
because _T_co used in typing.Iterable.__next__ was used instead thanks to
PyAncestorsTypeProvider. In other words, we inferred a TypeVar as a return
type of a method of a non-generic class. It led to retaining this TypeVar as-is
(not replaced) after substitution and SOE further down the road.
Ideally, the same should be done for other places where type hints can be used,
e.g. if a local variable has an explicit annotation, even an unresolved one,
no other type sources should be examined. Unfortunately, it's not as
straightforward for variables and parameters since their annotations sometimes
don't contain a type, e.g. x: Literal = 5, or x: Final = 5. It means
that we need to distinguish somehow between the cases "incorrect annotation, use Any"
and "this annotation requires further inference for the assigned value", and
our API doesn't allow to express that at the moment.
GitOrigin-RevId: 1bba57bb38718bcab7778049a91d5cbffb5e87c2
The original problem was seemingly fixed by the recent sync of Typeshed
(see 1b80465a7c72f89f48b22d35b69e4da4ea1efd46) where the declaration of _T_co
used in itertools.product.__next__ was moved from from _typeshed/__init__.pyi
to itertools directly.
The SOE was caused by the fact that due to unresolved _T_co in itertools.pyi
we retained _T_co type var in the result of product("bar", "baz") call. Then,
as a value of type list[_T_co] was passed as an argument to
list.__init__(self, __iterable: Iterable[_T]), we formed a mapping
{_T -> _T_co}, but the definition of list[_T] inheriting from Collection[_T_co]
itself added a mapping {_T_co -> _T}, hence we got a cycle.
The right way to handle such cases is introducing scope owners to TypeVars,
as it's being done in PY-53896, so that we can distinguish between _T_co's
coming from different class declarations, i.e. Collection:_T_co and product:_T_co.
Having a recursion check as a safety net is still beneficial, though.
GitOrigin-RevId: 7bebbe14931d44b12bc778f449f854d328169450
- minimizes calls to service in comparator
- cache fields are marked as volatile
- convert TreeSet to List before persisting with gson
(cherry picked from commit 7962bcbd91c4d619f9922668551cf9fd88c292a8)
IJ-MR-99615
GitOrigin-RevId: 85f91d6347e30de5014042904623b50058ede266
See KT-36770 in particular.
Note: beginning from Kotlin 1.6, we control nullability of type parameter-based
types more strictly. For example, it's not allowed to pass something of type 'T'
when '@NotNull T' or 'T : Any' is required. It's correct both for K1 & K2.
(cherry picked from commit a2f95c85d2673ff4688cd38aeacb5030df6000a8)
IJ-MR-99516
GitOrigin-RevId: d91601956a53489f29bc72b32e4810122ede0b1c
Using `Sdk.getHomePath()` as the path to interpreter is not reliable for every case. For example, for legacy remote interpreters `Sdk.getHomePath()` contains prefix, which is used to distinguish different types of remote credentials (for example `sftp://` or `docker://`). It also contains the representation of the value of the remote credentials used. In this case the interpreter path is available via `PythonSdkAdditionalData.getInterpreterPath()`.
These changes fix the problem introduced in c63b57aac9b5a267b3a6710902670bfe7d10c722.
GitOrigin-RevId: a7dc2579d1b0b367353fbecf4b9fe4a56b098e9b
Console should always be UTF-8 regardless any settings. The reasons are:
* This is how it worked before
* Not all one-byte encodings could be used on Python side
We set charset in 3 places:
* CommandLine/PythonExecution
* Env variable
* Console view.
GitOrigin-RevId: 595424d765979330bc0b6303c7267c8e0bff4887
We can't call ``getOrCreateAdditionalData`` from inspection since nothing could be changed from analysis.
GitOrigin-RevId: b133797dc765c4548461f3faf4b7d2358fa9e130
