as it's especially tedious to re-format them each time afterwards and
being surrounded with brackets they are safe to be moved to RHS of an
assignment.
Alternatively, we could leave such inlining only for binary expressions
since they can become syntactically illegal when moved out of the
context with implicit line joining (PY-2862).
Update PyInspectionVisitor to init type eval context from context file for injected fragments.
Update TypeEvalContext to check if passed element is inside injected fragment in origin.
Make PyDocstringFile inheritor of PyExpressionCodeFragment so
PyResolveUtil.resolveImportedElementQNameLocally could resolve element used in type comment.
Create quick fix so call expression could be easily replaced with subscription.
Otherwise, we end up not displaying overloads in cases when there is no
actual definition to resolve into. First of all, in case of builtin
declarations in typeshed.
Not as we see these variable types inside a function body, i.e.
just "**kwargs: Type" instead "kwargs: Dict[str, Type]" and
"*args: Type" instead of "args: Tuple[Type, ...]".
Similarly to normal parameters we don't show those keyword arguments
that are not explicitly present in function signature and can't be
passed in because of absence of **kwargs parameter.
Additionally, I enforced the order in which sections appears, so that
information about parameters, return value and raised exceptions
was always first and also fixed the way we show single star parameter
in signatures.
Otherwise, getParamDescription(), getReturnDescription() always return
non-empty string and we can't use it do determine whether a parameter
was actually mentioned in a docstring. Besides, it's inconsistent with
other docstring formats and really unnecessary since we no longer
display types and descriptions in the same place.
This change effectively reverts PY-7006.
similar to that used in JavaScript documentation
(JSDocBuilderMethodInfo). Namely, insert line break if the line before
containing the last parameter is longer than 80 characters.
It's not necessary as in Quick Documentation a definition is wrapped in
<pre/> tag according to new guide lines, and in tooltips line breaks are
preserved thanks to UIUtil.getHtmlBody() used in HintUtil.prepareHintText().
Similarly to how it's done for Java and other languages parameters are
wrapped and aligned always if there are more than one of them. Also, the
need to wrap the return type annotation is detected naively by checking
whether the length of the last line containing it exceeds 80 characters.
