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
This behavior is similar to how mypy and pyright handle overloads relying on
their definition order, where more specific signatures are supposed to precede
more general ones. The subtle difference is that in case of Any arguments,
pyright tries to find a common supertype for return types of all matching
overloads, mypy just returns Any, and we return a union of their return types.
For the time being, it keeps things simple and matches how we treated ambiguous
signatures before.
To make this work, I've had to revise how we handle name redefinitions in files.
Previously, we processed them in the reversed order to give priority to those
later in a file, which is natural for regular .py files. It doesn't make much
sense for .pyi stubs, though, as it's impossible to redefine a name there and
multiple definitions, e.g. overloads, are supposed to have equal precedence.
Now, we don't reverse the order of name definitions in .pyi stubs at all,
and in .py files we do that preserving the original order of overloads.
A side effect of it is that now we always navigate to the first overload
of a name in a .pyi stub, as opposed to the last, but it only seems more
logical and convenient.
On the other hand, when we handle overloads in .py files, we explicitly
assign to them a lower resolve rate to give precedence to implementations.
The only exception is that when there are no implementations we still want
to prefer the latest overload, so we put it into the results second time
with a higher rate. It messed up overloads order important for type inference,
so I've introduced a dedicated RATE_LIFTED_PY_FILE_OVERLOAD rate for such
results to filter them out later in PyCallExpressionHelper. I've also added
a named RATE_PY_FILE_OVERLOAD rate of other overloads in .py files to make
them more easily distinguishable from other resolve results with a low rate.
GitOrigin-RevId: e921654e47fe1fc5da047950b70775e342996757
Support | syntax for python unions.
Also support type | None as a new style for Optional.
Fix highlighting unresolved reference issues with | syntax.
Type inference from isinstance and issubclass.
Add quick fix to switch to old-style syntax in earlier python versions (<3.10)
Fix quick documentation to render new syntax.
(cherry picked from commit 6a64ee12c2d8503a0ef102e8b67cb0b95ce77999)
IJ-MR-8400
GitOrigin-RevId: c26b868fc61f26936a3316ec06f78b66d75f6857
Previously, we looked only for __init__.py to detect re-exported names,
ignoring __init__.pyi that could be used for the same purpose in stub
packages.
GitOrigin-RevId: 48bc58789e47d5b9fb814b99722371fdd670ee2d
It will fix PyTypeTest.testListTypeByModificationsConstructor and PyTypeTest.testDictTypeByModificationConstructor.
Callee has been resolved to overloads for a long time, it's better to filter out unmatched ones instead of calculating the same call type for every overload. Implemented in PyCallExpressionHelper.
Unify inferring call type for subscriptions and calls.
Union types order in test data has been changed since named elements are collected in reversed order in py files.
Repeat PyTypeTest.testCallableInUnion behaviour in PyTypeTest.testSubscriptionOnWeakType.
PyCallExpressionHelper.forEveryScopeTakeOverloadsOtherwiseImplementations has been updated to preserve elements order.
GitOrigin-RevId: f88eacd0a36dd5fbc59447db9dd4484d5a000bc8
Forward references resolution implemented for annotations according to
PEP 563. Inspections fixed to respect forward references for both
annotations and pyi stubs.
PyiReferenceResolveProvider removed since its functionality is now
implemented by PyForwardReferenceResolveProvider.
We used to exclude all the Any types from matched overloads even though
the match was successful. Now we stop analyzing an overload immediately
when the actual arguments don't match against its parameters.
Update registering type checking problems for binary expressions:
* prefer left operators over right ones
* in case of one operator register problem in the old way
* in case of some operators register problem on the left or right argument
Update multi-callee problem registration in PyTypeCheckerInspection:
* drop callees with unmapped arguments or unfilled parameters
* in case of one callee show message in old way
* in case of some callees show message with actual types and possible sets of them
It's their responsibility to provide the final return type for a function.
Only inferred (i.e. when there's no additional type hints) return value
types should be postprocessed like that in order to get not the
immediate type of values in return statements but the properly
parametrized special type from typing for genetators and coroutines.
Otherwise, we might end up returning something like
Coroutine[Coroutine[int]] for coroutines annotated using .pyi stubs,
because we don't take into account that PyiTypeProvider already
wraps the return type from the stub's annotation in typing.Coroutine.
In particular, show unresolved refernces in generic bounds as Any.
We used to ignore these unresolved types which resulted in
incomprehensible warning messages.
This is necessary for @typing.overload.
Removed specialized code to check the default values of parameters
for NumPy as bad for performance (stubs->AST for every function with
default values). We'll replace it with another workaround.
The test of overloads in Python stubs still fails since this union
type isn't used when analyzing function calls and matching arguments
against formal parameters.
