A destructuring declaration `val (a, b) = subject` introduces a temporary that
holds the subject; each component is then read from it via `componentN()`. The
two frontends represent that temporary differently:
- K1 names it `tmp<N>_container` and locates it at the subject expression only
(e.g. `7:26:7:26`, pointing at `p`).
- K2 names it `<destruct>` and locates it across the whole destructuring
declaration (e.g. `7:9:7:26`, `val (first, _) = p`).
Decision: adopt the K2 representation from both frontends. The `<destruct>` name
is uniform and frontend-independent (K1's `tmp<N>` counter cannot be reproduced
under K2, consistent with C14a), and the full-declaration span is more
informative than a bare pointer at the subject.
Implementation: `isDestructuringContainerVariable` recognises the temporary by
its frontend name (`<destruct>` under K2, `tmp<N>_container` under K1).
`extractVariableExpr` then emits the name `<destruct>` and, under K1 only, a
PSI-based location spanning the enclosing `KtDestructuringDeclaration`
(`getPsiBasedDestructuringContainerLocation`); under K2 the IR offsets are
already correct so the helper returns null and the existing location is kept.
Full dual-suite relearn: all 3333 tests pass. The only changed row is in
query-tests/UnderscoreIdentifier, where the K1 container converges from
`7:26:7:26 | tmp0_container` to `7:9:7:26 | <destruct>`, matching K2. With this
and C15, query-tests/UnderscoreIdentifier is now byte-identical across both
suites. The for-loop destructuring shape (`for ((v, i) in ...)`, where K1 omits
the container entirely) is a separate AST-shape difference tracked as C14c.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The local variable declaration expression (extractVariableExpr) computed its
location via getPsiBasedLocation(v as IrElement). The `as IrElement` cast forced
overload resolution to the generic getPsiBasedLocation(IrElement), which resolves
the PSI element straight from the IR element's raw source offsets via
PsiSourceManager.findPsiElement. Those offsets differ between the two frontend
language versions:
fun f(param: Int) {
val local1 = 2 + 3 // line 6: ` val local1 = 2 + 3`
}
- With -language-version 1.9 the IrVariable offsets cover only the name, so
findPsiElement returns the name leaf and the variable is located at 6:13:6:18.
- With -language-version 2.0 the IrVariable offsets cover the whole declaration,
so it is located at 6:9:6:26 (the `val` keyword through the initialiser).
The IrVariable-specific overload getPsiBasedLocation(IrVariable) is frontend
stable: it finds the leaf at the variable's start offset, walks up to the
enclosing KtVariableDeclaration and returns the span from the `val`/`var` keyword
to the end of the declaration. Using it for the entity location makes both
language versions emit the full declaration span 6:9:6:26.
This is the same helper already used for the enclosing localvariabledeclstmt
location; this change applies it to the variable entity (localvars / the
localvariabledeclexpr) as well, so the two are consistent.
Effect: 12 test-kotlin1 expected files move toward the test-kotlin2 output (all
strictly reduce the tk1-vs-tk2 difference; e.g. variables 16->4, reflection
111->67, exprs 1759->1363 diff lines). test-kotlin2 output is unchanged (the
overload produces the same span there as the generic one did). Both suites pass
all 3333 tests with --check-databases.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Also update the enhanced-nullability Kotlin integration test expected: its
local variable declaration expression now spans the val/var keyword to the
initialiser (user.kt:2:7:2:7 -> user.kt:2:3:2:16), consistent with the
library-test convergence.
K1 IrProperty.startOffset includes leading modifiers (private, abstract,
lateinit, annotations) in the span start; K2 already starts at val/var.
Walk the PSI tree from p.startOffset to the enclosing KtProperty, then use
valOrVarKeyword.startOffset as the declaration start, giving a consistent
start in both K1 and K2.
Two related but distinct locations are derived from the KtProperty:
- The property itself spans val/var through the end of the full
declaration (KtProperty.endOffset), including an explicit getter/setter
body on a following line. This is getPsiBasedLocation(IrProperty).
- Synthesised accessors (DEFAULT_PROPERTY_ACCESSOR origin) span val/var
through the end of the property name (KtProperty.nameIdentifier.endOffset)
via getPsiBasedAccessorLocation, applied through accessorOverride().
Explicit getter/setter bodies keep their own independently computed
location.
This makes K1 accessor locations match K2 and gives each synthesised
accessor a precise span, rather than the property's full declaration span.
Example (properties.kt line 3, "var modifiableInt = 1"):
property modifiableInt -> 3:5:3:25 (val/var .. end of "= 1")
accessor getModifiableInt -> 3:5:3:21 (val/var .. end of name)
accessor setModifiableInt -> 3:5:3:21
Because accessor locations appear wherever accessors are reported, this
refinement updates many expected files (property listings, modifiers,
methods, reflection, control-flow and expression dumps). Every change is a
location-coordinate change only: no result tuple is added or removed.
The PSI-based location is restricted to unspecialised extractions
(classTypeArgsIncludingOuterClasses.isNullOrEmpty()). Specialised generic
instances (e.g. C<String>.prop) continue to use the binary whole-file
location returned by getLocation(p, typeArgs), preserving the existing
behaviour that keeps them absent from fromSource() queries.
The visibility merge in extractFunction is extended to accept an
overriddenAttributes parameter from the caller; the internal fake-override
visibility adjustment (DescriptorVisibilities.PUBLIC for Java binary Object
methods) is merged with any caller-supplied attributes so that neither
overrides the other silently.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
In K1 mode, IrVariable.startOffset points to the name identifier and
IrVariable.endOffset is also at the name end, giving a location that
covers only the variable name (e.g. "local1") rather than the full
declaration ("val local1 = 2 + 3").
In K2 mode the IR offsets already point from the val/var keyword to the
end of the initializer, matching the intuitive source span.
Fix this for K1 by adding an IrVariable-specific overload of
getPsiBasedLocation that:
1. finds the leaf PSI element at v.startOffset (the name identifier)
2. walks up to the enclosing KtVariableDeclaration (KtProperty)
3. uses the val/var keyword position as the start offset to exclude
any leading annotations from the span
This matches the K2 IR behavior and gives a more complete location for
variable declarations when used in CodeQL queries.
The fix applies to both K1 and K2 since the overload is unconditional;
for K2 the walk-up gives the same result as before.
Expected updates in test-kotlin1:
- variables: local variable locations now span from val/var to initializer
- exprs, stmts, methods, modifiers, reflection: same local variable span
- controlflow/basic: CFG node references updated for new variable spans
(the "var ...;" node now starts at the val/var keyword)
Class member and top-level properties (IrProperty, not IrVariable) are
not affected by this change and retain their existing location behaviour.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
