It was temporarily commented out during extraction of python-psi-impl and
forgotten in this state after all the dependencies have been resolved.
GitOrigin-RevId: d6b985229fbfeed0ac0086e84ad586617a6c3d10
It turned out that several existing type providers incorrectly processed PSI
stubs, returning nothing in cases when TypeEvalContext prohibits accessing AST,
but the containing file was already unstubbed, leading to inconsistent "flaky"
analysis results.
Since the pattern for safe accessing AST vs. stubs properly taking into account
both TypeEvalContext constraints and StubBasedPsiElement.getStub() is notoriously
tricky to get right, and it's not the first time to such problem was discovered,
we tried to hide this logic behind a new experimental API -- StubAwareComputation
and migrated those type providers to it. Other code insight parts that need to
operate on stubs, especially custom ones, might follow.
This change is a joint effort with Semyon Proshev who came up with an initial
draft of the new API and updated all the affected type providers.
GitOrigin-RevId: 2ea467d85a6d30e37049edacd5eb4a32768f5252
String nodes are recognized by the lexer and, thus, can still appear even in
syntactic contexts where an expression is not expected. In these cases the parser
might wrap them in a PsiErrorElement instead of a PyStringLiteralExpression causing
the reported CCE.
GitOrigin-RevId: 161d88d6307e028ede462f707f01320df2169747
The new implementation of "Go to Declaration or Usages" doesn't expect such
results from providers and intentionally just unconditionally leads to whatever
they return instead of showing usages in such cases.
GitOrigin-RevId: b3e63b36254e6ca1aca77030ee6ac56ff03308c9
- Added PyDecorator.getExpression() to reflect that in Python 3.9
an arbitrary expression can be used after "@". Reused it where possible
in the implementation.
- Removed hasPlainReferenceCallee() in favor of existing getQualifiedName().
Updated javadoc for the latter to clarify how it handles non-trivial callees.
- Added PSI stub tests to make sure that right values are still persisted
with the new flexible decorator grammar.
GitOrigin-RevId: 8109b834c8d257c72f6f6e3c0ce5005060a2b971
It's no longer detected by unresolved references inspection, because we can't
recognize versions guards in .pyi stubs and falsely assume __class_getitem__
to be available in all Python 3.x versions.
Moving this check to Type Hints inspection allows both to give it a more
descriptive error message and suggest a dedicated quick fix for replacing such
usages with the corresponding aliases from "typing" module.
GitOrigin-RevId: 5ae8bb7037bfd8f30ed1b1eb5b1a8824a8ed6ba9
It's not that easy for "Type[...]" because it can wrap a TypeVar and, thus,
not have a physical PSI element we can get the language level from.
GitOrigin-RevId: aaa2c4e3819f4368f019c491f11e51d8dbaec701
The main idea here is that we also automatically convert the containing string
literal into a proper f-string upon selecting one of such variants.
Hopefully, it addresses the common problem of forgetting to add "f" prefix
before an interpolated (in mind) string literal in a more discoverable fashion
than a dedicated intention or a postfix template would.
GitOrigin-RevId: f59065abeb4a3b0cd7a0de42c9c06c9fad318b19
Possibly PY-32905 and PY-32788 are fixed.
No more need to provide callable type for `typing.TypeVar` because of https://github.com/python/typeshed/pull/4150
GitOrigin-RevId: f45928ad3b6ab18866b543bd2f375faa92d79b41
