The previous version of this query inadvertently excluded constants
which weren't classes or modules. This version includes them, by
introducing a laxer version of `resolveScopeExpr` that doesn't require
the result to be a `TResolved`.
By convention, instance variables are considered to be "defined" in the
`#initialize` method of their containing class. If an instance variable
is written to in `#initialize` and then read elsewhere in the program,
we will point from the read to the write. If it is not written to in
`#initialize` then we won't provide any jump-to-definition information
for it.
We synthesise variables for things like tuple patterns. For example,
this Ruby code:
a, b = ...
becomes:
__synth__0 = ...
a = __synth__0[0]
b = __synth__0[1]
The `__synth__` variables should be ignored when calculating
jump-to-definition information, since they don't appear in the original
source code.
The expected output format is a tuple (a, b, k) where `a` and `b` are any
`AstNode` subclass and `k` is a string indicating the kind of
definition (e.g. variable, method, ...).
By ensuring that every value in `DefLoc` is a subclass of `Expr` (itself
a subclass of `AstNode`) we can simplify the query by removing all the
use of `getLocation()`.
The base `PrintAstConfiguration` class already has a predicate for
filtering out desugared nodes - this change just makes use of it in the
query.
This fixes https://github.com/github/codeql-team/issues/408, which was
caused by including nodes representing the desugaring of
a[b] = c
in the query output. This would result in multiple edges to the same
target node (one from the surface AST and another from the desugared
AST), which the VSCode AST viewer cannot handle.
