Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: f1b80125c2555d89f32aae4e5290d7771a357abf
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: b442e8499110d543d5ec05b9e07f6c0f88b61ecc
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: 30586ed1915e3b35394ff3ee6251607c64bbabdd
Now we have Code Vision hints which determine the author via Git history and show it in the editor automatically, and this information is more accurate than the tags which were automatically added when files were created.
GitOrigin-RevId: 474de1bafc0651b90f08384cf04094eff9466115
- when there are other keys present in the literal, use quotes from there
- when the literal is empty, use double quotes by default
- when there already are quotes, suggest just the key names
GitOrigin-RevId: 5f37cd25c0e47521e78a01ab84053571369b24a8
_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
Without this fix `ProjectJdkTable` contains two identical SDKs and it leads to incorrect behaviour later. One is added implicitly via `PySdkExtKt.setPythonSdk` another explicitly in test `ProjectJdkTable.addJdk(com.intellij.openapi.projectRoots.Sdk)` but without check for duplicate. And later in test after SDK remove, `ProjectJdkTable` still contains one link to the disposed SDK and it's incorrect.
GitOrigin-RevId: a15c443007ad3f3106001dc4abadad2989d20073
Namely, ignore everything starting with a known tag and until the closing
colon. It should match constructs like ":return:", as well as
":param list[int] x:". Excluding just the tags is not enough,
as the following identifier and colon are still recognized as part of
a grammatically-incorrect sentence.
In other languages, where markup elements in documentation comments have
their own PSI elements, this exclusion is easier. Maybe we should do the
same for reStructuredText directives at some point.
GitOrigin-RevId: 9c50148097d3e27fe79cdc0a9aa90a7946b215ca
* Set ``use.python.for.local.conda`` (true by default)
* Use ``addCondaPythonToTargetCommandLine``: it either adds ``python`` or ``conda run`` depending on this setting
GitOrigin-RevId: b727382ec3b7a38338e1449bd592add540637626
See ``TargetedCommandLineBuilder.addEnvVars`` doc for the main issue.
We also add fix to patch path in PythonScripts
GitOrigin-RevId: f42044338f91d5b444c5e1431957272392ab5f1c
What was wrong:
For SDK creation we execute python to get python path for homePath (see ``PyAddCondaTools``).
So, we execute python on conda before homePath set.
On each execution we read vars from ``activate.bat`` to workaround conda SSL in path problem and activate terminal (since cmd in terminal still uses old API).
``PySdkUtil`` can't read vars when homePath not set, hence caches empty vars for SDK and both terminal and conda workaround stop working until IDE restart.
We now stopped caching empty vars if homePath is empty.
GitOrigin-RevId: de3e37bbbc5281775e3fca79840089561ceed189
Conda failed to load OpenSSL dll on Windows. It does so due to bug in ``conda.bat`` machinery that doesn't add required dir to the ``PATH``.
However, when you activate conda (``activate.bat``) it works. As workaround, we revert old behaviour: read ``activate.bat`` and fetch list of env vars (``PATH`` including). See comment in ``PyCondaEnv``
GitOrigin-RevId: 0238b7308043d8ff73d026f5ce231a993f9d9240
