Previously, we reported call arguments only if either all callee
candidates have unmatched arguments or all call candidates have
unmatched parameters. When there was a mix of the two, we reported
nothing.
(cherry picked from commit 97b42faf10de74ee7cd10f934d9eb94e1c8bbb34)
IJ-CR-146869
GitOrigin-RevId: 8babfe6a8ad0152f985655eff27df4df68936594
Reword the inspection text
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
(cherry picked from commit cab3cb1bbb1316462ee3fd37e735765b31b8d5e8)
GitOrigin-RevId: e3288e503d714a1f76bd1a2e6a0553770e1cbad5
* Remove unnecessary descriptor type inference from `PyTargetExpressionImpl.getType`
* Refactor overload resolution for synthetic calls, minor refactorings in PyDescriptorTypeUtil
* Add additional test for __set__
* Do not substitute missing argument types with implicit `Any` in PySyntheticCallHelper
* Always take the first overload for `__set__` if more than one is present
(cherry picked from commit 9d1f9d37f3ea23ce6145f82fc8f62212f744e858)
GitOrigin-RevId: 372dc0e8ccc32095aecf3f611645adc06c2873e9
Add API for inferring the expected type of `__set__` from `value` parameter
Add corresponding logic to PyTypeCheckerInspection to check if assigned value matches the expected descriptor type
Add tests on it
(cherry picked from commit b14ab7b2e40e225b508875a778ceae8986cbb291)
GitOrigin-RevId: 2b15b2b4527a95e5912897ba256dcc73d71c3dcd
The implementation is very similar to the PyTypeShed,
it should be merged into more general solution.
GitOrigin-RevId: 1449a774e93206349f17f264c27e2a7877d79b19
Protected member should not be highlighted as a warning if it resolves to .pyi file.
We assume that everything in .pyi file is a public API.
GitOrigin-RevId: c8275f3e48e3cd69b1676de9b78606f28ea224c8
There were two underlying problems in Kotlin code:
```
run { DjangoFQNamesProvider.ACCEPTS_VIEW_NAME.isNameMatches(this) } != null
```
returned true regardless of the result of `isNameMatches(this)` call.
As a result, we used to suggest Django view names for *all* functions called
"reverse", "redirect" or "reverse_lazy".
Secondly, in FQNamesProviderExtKt.isNameMatches:
```
return getQualifiedNames().any {
return it.firstComponent == elementQualifiedName.firstComponent &&
it.lastComponent == elementQualifiedName.lastComponent
}
```
always returned the result of comparison with the first qualified name, ignoring the rest
due to non-local return from the inline `any`.
Finally, DjangoUrlViewProvider.isReverseFunction expected a PyFunctionType as the type
of reverse/redirect/reverse_lazy, but since these functions have overloads in .pyi
stubs we started to infer a union type of PyFunctionTypes for them, breaking the reference
provider. In general, it's better to perform a name resolution instead of type inference
to detect a fully qualified name for a reference.
GitOrigin-RevId: 69949b1b0e65f00557536cf16127279a83ea4f9d
1. At first, get rid of the explicit mapping of generics to default types (remove all these not-good-looking methods which were added earlier, such as `PyTypeChecker.trySubstituteByDefaultsOnl`y and `PyTypeChecker.getSubstitutionsWithDefaults`) and their usages. All the related logic now will be handled in `PyTypeParameterMapping`, as we wanted it to be.
2. Do some changes in `PyTypeChecker` to be able to correctly parameterize class via constructor call, and also take defaults into account in `PyTypeChecker.getSubstitutionsWithUnresolvedReturnGenerics` for methods
3. Get rid of the explicit calls of `PyTypingTypeProvider.tryParameterizeClassWithDefaults` in `PyCallExpressionHelper`, `PyReferenceExpressionImpl`, rename this method to `parameterizeClassDefaultAware` and call it directly in `PyTypingTypeProvider.getReferenceType`
4. Add a new flag to `PyTypeParameterMapping` to be able to correctly match type parameters (see `PyTypeChecker.matchTypeParameters`)
GitOrigin-RevId: 5dd90ee3bdf8319b36f1945ce22a33a8edf6bc93
typing.Generic is a magical class that can be specified in any position
in the list of base classes, not affecting the MRO consistency. It's done by
the custom __mro_entries__ implementation in typing._BaseGenericAlias (Python < 3.12),
which skips this Generic entry if there are other generic classes following
it on the list of superclasses. Namely, it's possible to do the following:
```
class Base(Generic[T]):
pass
class MyClass(Generic[T], Base[T]):
pass
```
which would cause a TypeError for regular classes. Since it broke our implementation
of the C3 algorithm in PyClassImpl.getMROAncestorTypes, we now special-case it by
always moving typing.Generic to the very end of the base class list while constructing
MRO.
See https://github.com/python/cpython/blob/3.11/Lib/typing.py#L1298 for a pure-Python
version of typing._BaseGenericAlias.__mro_entries__ and a relevant discussion in
https://github.com/python/cpython/issues/106102.
GitOrigin-RevId: e7d765193d532ab8457133e8fb5ad06840d89225
Also fixes PY-59014, PY-39761.
PyResolveImportUtil returns both .pyi stubs and the corresponding .py files for stub packages
to support partial stub packages. See the line:
```
groupedResults.topResultIs(Priority.STUB_PACKAGE) -> firstResultWithFallback(groupedResults, Priority.STUB_PACKAGE)
```
in PyResolveImportUtil.filterTopPriorityResults.
It means that, for instance, resolving the QuerySet name in type hints led to QuerySet
definitions from both places. Then, PyTypingTypeProvider.getType() for the reference expression
"QuerySet" returned a union type containing PyClassTypes for both of them, we couldn't parameterize
it in PyTypingTypeProvider.getParameterizedType and returned Any.
It's wrong that while evaluating type hints, we interpret multiple declarations as
a union type. Those should only be explicitly expressed with typing.Union or "|" operator.
This behavior was originally added in PY-18427 as an ad-hoc way to support version checks
for type hints, but now it seems detrimental because it's unclear how to parameterize
such implicit unions of generic types then.
Other type checkers also don't treat conditional definitions like that. For instance, for
conditional type aliases, Mypy complains about the name being defined twice and then uses
only the first definition, and Pyright doesn't consider names under conditions other than
version checks as valid type aliases at all. Both type checkers also support partial stub
packages properly.
GitOrigin-RevId: 1ecc7ab5d09625d10850ddc0e1f7761332ccddd5
add new features: info about underscores in path, info about lib location, info about context of original file(extension type, psi parents, size of project),
info about already existing imports from the same library(in this file, in other opened files, in other files in the same directory)
GitOrigin-RevId: ca8206d4d7db6bc79e8f1a78502bf33696a653e9
sys.version_info guards are processed at the level of ScopeImpl.collectDeclarations and
PyResolveUtil.scopeCrawlUp in PyReferenceImpl.resolveInner, as implemented in
3318ff79cdcc5ba0ce5e4feb65abad5ad0f4acfa.
However, once we collected all name definition candidates flow-insensitively this way, in
PyReferenceImpl.getResultsFromProcessor, if the reference and these candidates were located
in the same scope, we completely ignored these variants and gathered reachable definitions all
over again from CFG using PyDefUseUtil.getLatestDefs. And the latter didn't consider version
guards at all. I've added version guard checks directly in PyDefUseUtil.getLatestDefs.
GitOrigin-RevId: 9f92eecd1eb1812bfbd2bf54f8192f45f0cf0a1d
The refactoring also fixes the problem with wrong types inferred for contextlib.contextmanager
GitOrigin-RevId: 1601047786a0c43a463a82225b18635d407bcb40
