> That no ignore annotation can be applied to any but the first line in a line-continued statement is a direct effect of the current scoping of our annotations. These always apply to the first physical line below them, i.e. the first line in the editor below them.
Since it is impossible to add comments on any but the last physical line of a line-continued logical line, it is currently impossible to apply an annotation to anything not in the first physical line of a logical line.

Changing thi

> I cannot reproduce this with the current version of RD. Could you check whether the problem is still there for you.
If memory serves right, there was an overhaul of this inspection at some point.

Should the issue still be there, could you verify whether you also see the problem if you use string literals as arguments?

> Closes #5845

This inspection usually ignores arrays because they are technically valid without assignment. Moreover, it is a bit unclear what it means for them not to be assigned. (one index vs. all indices)

In the case of a Variant used as an array without an assignment to it, which is possible using a ReDim statement, we do not know that the variable represents an array. So, an inspection result was issued, although some or all array slots were assigned to.

To deal with this, a new

> Closes #5853

Previously, we did not always determine correctly whether there is a member access on the return value of a function. The problem was that the reference in a member access expression goes to the unrestricted identifier while it goes to the whole simple name expression in case of a simple name expression. This makes it necessary to deal with them in different ways; the first member access parent of a reference to a member access is the member access itself while it is a further

> This PR intends to address the issue #5782.

While it does not really fix the root issue while resolving the supertypes of certain controls in Access, it should stop the reolver from bailing out completely.

In general, the implicit contract of the binding contexts has always been to return a failed resolution binding whenever the resolution fails. Unfortunately, that was not actually the case, if unexpected context types were encountered while building the expression tree. To remedy this,