mirror of
https://github.com/github/codeql.git
synced 2026-07-14 07:48:16 +02:00
db88f07a3a
An explicit property accessor may carry its own annotations, for example:
val x: Int
@JvmName("getX_prop")
get() = 15
The K2 frontend records such an accessor with raw IR offsets that begin
at the leading annotation; the K1 frontend's raw offsets start at the
`get`/`set` keyword and omit the annotation. This is a pure K1
information regression: the annotation is part of the accessor
declaration and the K2 span is the more faithful one, so we converge K1
onto K2.
Because the annotation-inclusive start cannot be reconstructed under K2
(no PSI back-mapping) but is trivially available under K1, we recover it
from the KtPropertyAccessor PSI node, whose text range begins at its
modifier list. A new helper getPsiBasedAnnotatedAccessorLocation returns
this span, and accessorOverride now applies it to explicit accessors (in
addition to the existing synthesised-accessor handling).
Guards keep the change surgical:
- returns null under K2 (getKtFile unavailable; raw offsets already
include the annotation), leaving K2 untouched.
- returns null when the accessor declares no annotations of its own, so
non-annotated explicit accessors (which already converge) are
unaffected.
Relearned both suites: only explicit annotated-accessor declaration rows
change (K1 now matches K2). annotations/jvmName/test.expected becomes
byte-identical across suites; the residual diffs in jvmstatic-annotation
are pre-existing, unrelated divergences (JVM-static proxy forwarder
locations and call-argument spans).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>