It's weird, however, that Python implementation might query fixers for elements
that are at completely different lines with the caret as in the originally
reported case. This confusing and error-prone behavior needs to be revised
separately.
GitOrigin-RevId: 1f48fe0e0936fb2007022dfc889c44ad32e1eaf0
It works by automatically inserting a trailing comma before a line break in
multiline collection literals. Additionally, a colon is inserted between a key
and a value in dict literals.
Because of the language ambiguity regarding syntax of some incomplete collection
literals, colon is not inserted after the first key of a dict literal
(it's indistinguishable from a set literal with one item), and comma is not
inserted after the first item of a parenthesized tuple (it's indistinguishable
from a parenthesized expression).
The idea was taken from such implementation of Complete Current Statement for
JSON.
GitOrigin-RevId: 49ff9857d8c12476bfa9aacaed0b49faa99810fd
- treat deletion by slice and subscription expressions as read access
- delete instruction in dataflow only inserted for PyReferenceExpression
GitOrigin-RevId: 72ae5e964a1e287e007dabb8f41433b284523a02
self is inserted for methods that are not class-/staticmethod
cls is inserted for classmethod
empty parameter list for staticmethod
GitOrigin-RevId: 9743ae50c89c069b8123b8b6eb26fb841dd1f5b2
There is no edge between loop statement and next after loop instruction
when loop has at least one iteration
so `continue` is marked as one more last instruction in the loop
but properly take them into account in PyClassType#getMetaClassType().
This check was implemented there instead of PyClass#getMetaClassType()
itself, since the former method already looks up for explicitly declared
metaclasses in ancestors unlike PyClassImpl that considers only those
specified directly in the class definition or its containing module.
Moreover, there are actual usages that expects such behavior from
PyClass#getMetaClassType(), e.g. PyAbstractClassInspection.
in case this relationship was created implicitly by inheriting an
instance of metaclass.
It also fixes warnings about the first parameter of SQLAlchemy model
methods being named "self" instead of "cls" since we no longer consider
these classes descendants of "type".
to handle, in particular, lazy initialization scenarios
For instance, the statement "foo.bar = 42" should add a node
"WRITE ACCESS foo.bar" containing the corresponding target expression.
Additionally, "Unused local" inspection doesn't consider writes to
attributes, since, strictly speaking, these are not local names.
The check that we should add such synthetic node only if there were no
pending edges inside the body of if statement (e.g. if it contained only
break/continue/return for the enclosing loop) seems doubtful and
doesn't cover the simplest/most common cases.
Otherwise it's impossible to flow-sensitively resolve names referenced
inside such f-strings since we use the containing statement as the anchor
node in the graph.
The problem itself has been already remedied by the previous fix,
nonetheless, the example given by the user provides an interesting
case where we can encounter duplicate base classes in practice,
since we are not able to find out result of type(SomeClass) expression
yet.
The exception could happen in this case because we used the same cached
result of MRO linearization twice without defencive copying. Then later,
as a side effect of that, in mroMerge() we deleted one "head" from
several sequences simultaneously, hence the IndexOutOfBoundsException.
Some of the ancestor class-like types may be unresolved. The best we
can do is to put nulls for all the unresolved classes to appropriate
places inside the MRO chain. What we used to do in this case it return
the empty sequence of the ancestors.
