f1ccb6bda0
The synthetic setter of a *delegated* property has one implicit value
parameter. The K2 frontend names it `<set-?>`
(`SpecialNames.IMPLICIT_SETTER_PARAMETER`), matching what it does for an
ordinary member property's setter. The K1 frontend instead names a
delegated property's setter parameter `value`, diverging from both K2 and
from its own naming of member-property setters.
This produced two divergent rows per delegated `var` between
test-kotlin1 and test-kotlin2 (the `[Parameter]` declaration and the
`[VarAccess]` that reads it back inside the generated setter body):
- [Parameter] value -> [Parameter] <set-?>
- [VarAccess] value -> [VarAccess] <set-?>
Decision: adopt the K2 name. `<set-?>` is the canonical implicit
setter-parameter name the frontend already uses everywhere else, so it is
the more consistent and less surprising choice; a bare `value` is
indistinguishable from a user-written parameter of that name.
`getConvergedValueParameterName` renames the parameter only when its
enclosing function has origin `DELEGATED_PROPERTY_ACCESSOR` *and* its K1
source name is `value`. The origin guard restricts the rename to the fully
synthetic delegated accessors (a hand-written `ReadWriteProperty.setValue`
has origin `DEFINED`, so its `value` parameter is untouched); the name
guard restricts it to the setter value parameter, leaving the accessor's
receiver parameters (`<this>` for an extension property,
`<dispatchReceiver>` for a member property) unchanged. Under K2 the setter
parameter is already `<set-?>` and receivers are `<this>`, so nothing
matches and the canonical K2 output is byte-for-byte unchanged (only the
three K1 setters in test-kotlin1 relearn).
The literal `<set-?>` is used because `SpecialNames.IMPLICIT_SETTER_PARAMETER`
is not resolvable in every compiler version the extractor is built against.
Relearned both suites (all 3333 tests pass); only the three delegated
setters in test-kotlin1 (delegatedProperties.kt lines 19, 34, 82) change.
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.