mirror of
https://github.com/github/codeql.git
synced 2026-07-13 23:38:15 +02:00
a55f7caab5
A primary constructor's call to its superclass is written in source only
as a supertype-list entry (for example `class C : Base()`), so the
synthetic delegating super-constructor call has no `super(...)` token of
its own. The K1 frontend records it at that supertype call expression
(`12:23:12:34`); the K2 frontend records it at the whole class
declaration (`12:1:15:1`).
Neither is a real `super(...)` statement. Consistent with the location
policy adopted for these synthetic constructs (prefer the fuller
whole-construct span), we converge K1 onto the K2 form.
Because the whole-class span cannot be reconstructed under K2 (no PSI
back-mapping) but K2 already emits it from raw IR, the fix is K1-only: a
new helper getPsiBasedPrimaryCtorSuperCallLocation returns the enclosing
KtClassOrObject span (including leading modifiers such as `open`) for the
super call of a primary constructor, and the IrDelegatingConstructorCall
handler uses it for super calls (delegatingClass != currentClass).
Guards keep the change surgical:
- applies to primary constructors only (both explicit `()` and fully
implicit); an explicit `super(...)` in a secondary constructor keeps
its own location, which both frontends already record identically.
- returns null under K2 (getKtFile unavailable; raw offsets already
carry the class span), leaving K2 untouched.
Relearned both suites: only primary-ctor super-call rows change (K1 now
matches K2). classes/ctorCalls.expected becomes byte-identical across
suites; the residual vararg/args diff is a pre-existing, unrelated
`public vararg val` parameter-span divergence.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>