d91b3899ae
For a property such as `val prop: Int = 1`, the compiler generates synthetic `this.prop` accesses (inside the default getter and the primary-constructor field initialiser). The K1 and K2 frontends give these synthetic accesses different source spans: * K1 runs the span through the initialiser: `variables.kt:3:5:3:21` * K2 stops at the end of the type signature: `variables.kt:3:5:3:17` The property *declaration* location is `3:21` under both frontends and is left untouched; only these synthetic *access* expressions diverged. The K2 signature span (val/var keyword to the end of the type, or to the end of the name when the type is inferred) is the more intuitive location: it points at the property's signature rather than incidentally swallowing the initialiser expression, so a `this.prop` read is not reported as spanning code it does not evaluate. We adopt the K2 span and reproduce it under K1 from PSI. New helper `getPsiBasedPropertySignatureAccessLocation` returns the signature span only when the access resolves (via `findPsiElement`) to the enclosing `KtProperty`, which is true exactly for these synthetic property-declaration-anchored accesses. It returns null under K2 (no PSI is available there, and the raw IR offset already gives the signature span) and for every ordinary source-written access (whose PSI is the reference expression, not the whole declaration), so canonical K2 output and normal accesses are unaffected. It is wired into the `IrGetField` read path and into `extractThisAccess`. Effect: tk1 `variables/variables.expected` becomes byte-identical to tk2; `variables/variableAccesses.expected` drops to only the separate implicit-`this` call-receiver span divergence; genericExprTypes/exprs/methods synthetic property-access rows all move from the through-initialiser span onto the K2 signature span. All 3333 tests pass in both suites; test-kotlin2 is unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.