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>
Synthesised and bare `get`/`set` accessors were extracted with different
source locations depending on the frontend:
val typedProp: Int = 3 // getTypedProp
K1: 5:5:5:17 (val..name) K2: 5:5:5:22 (val..type)
val defaultGetter = 7
get // getDefaultGetter
K1: 19:5:19:21 (property head) K2: 20:13:20:15 (`get` keyword)
Under K2 the extractor has no PSI back-mapping for these accessors
(`getKtFile` returns null), so it cannot reproduce K1's property-name-end
span; K2 instead falls back to the raw IR offsets. Rather than converge on a
value K2 cannot produce, K1 is made to match the K2-native spans via the PSI:
* a bare `get`/`set` keyword now points at the keyword token; and
* a fully synthesised accessor now spans the property signature
(`val`/`var` .. type annotation, or .. name when untyped), excluding the
initialiser.
Explicit-body accessors (`get() = 5`) are unaffected: they are located at
their body and never take this override.
Only K1 output changes; the test-kotlin2 (K2) expected files are unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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>
