mirror of
https://github.com/github/codeql.git
synced 2026-07-15 00:08:14 +02:00
2121d74eb8
When a constructor carries leading modifiers or annotations, for example
`internal constructor(...) { }` or an annotated `@Ann constructor()`,
the K1 frontend's IrBlockBody offsets for the constructor body begin at
the modifier/annotation (`3:3`); the K2 frontend begins at the
`constructor` keyword (`3:12`), consistent with how declarations exclude
leading modifiers from their own span. We converge K1 onto the K2 form.
The K2 span cannot be reconstructed from raw offsets under K1, but the
`constructor` keyword position is available from the PSI. A new helper
getPsiBasedConstructorBodyLocation walks from the block body's start to
the enclosing KtConstructor and returns a location from its
`constructor` keyword through the block body's own end offset;
extractBlockBody uses it in preference to the raw block location.
Guards keep the change surgical:
- returns null under K2 (getKtFile unavailable; raw offsets already
exclude the modifier), leaving K2 untouched.
- returns null for non-constructor bodies and for an implicit primary
constructor with no `constructor` keyword.
- for a constructor without modifiers the keyword coincides with the
block start, so the location is unchanged there.
Relearned both suites: only modifier/annotation-carrying constructor
body-block rows change (K1 now matches K2).
internal-constructor-called-from-java/test.expected becomes
byte-identical across suites; the residual annotation_classes/PrintAst
diffs are pre-existing, unrelated divergences (annotation-argument and
stdlib enum-entry locations).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>