* Renamed PyPsiUtil#getStatement to PyPsiUtil#getParentRightBefore as
this name more clearly describes method's functionality.
* Return Couple<PsiElement> instead of awkward two-items array or
PsiElements.
We couldn't do check for 'typing.Any' inside PyTypingTypeProvider, so
we had to put some 'typing' knowlegde into PyFunctionImpl and
PyParameterImpl which wasn't elegant. Also we couldn't combine
type information from annotations and default arguments that was
required for Optional[T] for 'x: T = None'. Now we can implement it.
Previously there was no way for a type provider to tell that the type
is really 'Any'. The 'null' return value was just a sign that the
provider doesn't know the return type and we should try other
alternatives.
Override removeChildInternal in PyGlobalStatement and
PyNonlocalStatement in similar fashion as it's done already in
PyArgumentList and PySequenceExpression, i.e. delete dangling comma
if any
The list of all the language levels was defined in
UnsupportedFeaturesUtil, so it was easy to forget to update it when
introducing a new language level. Now it's defined in LanguageLevel.
We cannot evaluate the result of an overridden mro() method, so we
don't know the actual MRO chain. Let's assume that MRO is almost the
same as without this override and add an element of uncertainty by
appending a fake unresolved ancestor type to the MRO chain. Doing so
results in, for example, the unresolved references inspection ignoring
unresolved references for such a class.
We used to have context.allowLocalUsages() for permitting a code
analysis to guess types from file-local function calls. This analysis
mode came into conflict with the new structural types, since they both
provided types for function parameters. Another problem is that the user
used to see the types inferred from local calls in the documentation
pop-up and it was not clear where did they come from.
The solution is to introduce a new type eval context for code completion
only named TypeEvalContext.codeCompletion() and allow file-local call
based type inference only in this context.
The 'x in y' expression implies that 'y' has the '__contains__'
attribute, while our references in qualified expressions tell that
the 'x' references the name '__contains__'. In order to fix this we have
to treat the operators with a receiver on the right side of the
expression differently.
Elements no longer inherit default presentation from
PyPresentableElementImpl. Most of the presentation logic has been moved
from PyStructureViewElement to getPresentation() of particular elements.
Added PyElementPresentation class that can be customized via
subclassing.