8267d331a4
A compiler-generated default property accessor (`DEFAULT_PROPERTY_ACCESSOR`)
has no source body, so the two frontends anchor its synthesised body
expressions (`field = value` / `return field`, plus their `<set-?>`, field and
`this` sub-accesses) differently:
- K1 anchors them at the whole `KtProperty`, whose end offset runs through the
initialiser (`var topLevelInt: Int = 0` -> `60:1:60:24`,
`var curValue = 0` -> `26:13:26:24` .. `26:28`).
- K2 has no PSI for these accessors and falls back to the raw signature span,
which stops at the type (`60:1:60:20`) or, when the type is inferred, at the
name (`26:13:26:24`).
The initialiser is not part of the accessor body (it runs in the field
initialiser / `<clinit>`, not in the setter), so K2's narrower signature span is
the more intuitive, information-preserving choice: it keeps the accessor's
synthetic expressions on the property signature and leaves the initialiser to
the genuine `KtInitializerAssignExpr` / `<clinit>` rows.
We converge K1 onto the K2 span with a scoped offset remap set only while
extracting the accessor body (mirroring the existing delegated-property-accessor
remap). The remap is keyed off the accessor's corresponding property and matches
the property's full IR range exactly, so:
- it only rewrites the synthetic body expressions that carry that range;
- the real field-initialiser rows (which share the same source text but are
extracted in the initialiser context) are untouched and keep their
initialiser-inclusive spans; and
- it is a no-op under K2 (no PSI, so `getEnclosingKtProperty` returns null) and
for any property without an initialiser past its signature.
Tradeoff: this converges K1 onto a span that K2 produces natively but that K1
cannot recover without the PSI, so the direction is fixed (K1 -> K2) rather than
chosen freely. That is acceptable here because the K2 span is the more correct
one on the merits (the initialiser does not belong to the accessor body).
Expected updates (K1 only; K2 already emitted these):
- library-tests/exprs/exprs.expected (setCurValue, setTopLevelInt)
- library-tests/methods/exprs.expected (clinit.kt setTopLevelInt)
Both suites relearned; all tests pass. Divergence 820 -> 798 rows.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 86bfc022-3ecc-4746-ba23-3b76c4e4c3e4
CodeQL
This open source repository contains the standard CodeQL libraries and queries that power GitHub Advanced Security and the other application security products that GitHub makes available to its customers worldwide.
How do I learn CodeQL and run queries?
There is extensive documentation about the CodeQL language, writing CodeQL using the CodeQL extension for Visual Studio Code and using the CodeQL CLI.
Contributing
We welcome contributions to our standard library and standard checks. Do you have an idea for a new check, or how to improve an existing query? Then please go ahead and open a pull request! Before you do, though, please take the time to read our contributing guidelines. You can also consult our style guides to learn how to format your code for consistency and clarity, how to write query metadata, and how to write query help documentation for your query.
For information on contributing to CodeQL documentation, see the "contributing guide" for docs.
License
The code in this repository is licensed under the MIT License by GitHub.
The CodeQL CLI (including the CodeQL engine) is hosted in a different repository and is licensed separately. If you'd like to use the CodeQL CLI to analyze closed-source code, you will need a separate commercial license; please contact us for further help.
Visual Studio Code integration
If you use Visual Studio Code to work in this repository, there are a few integration features to make development easier.
CodeQL for Visual Studio Code
You can install the CodeQL for Visual Studio Code extension to get syntax highlighting, IntelliSense, and code navigation for the QL language, as well as unit test support for testing CodeQL libraries and queries.
Tasks
The .vscode/tasks.json file defines custom tasks specific to working in this repository. To invoke one of these tasks, select the Terminal | Run Task... menu option, and then select the desired task from the dropdown. You can also invoke the Tasks: Run Task command from the command palette.