Skip to content

Added an annotation for function positioning in K2 TargetMarker #73

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 21, 2024

Conversation

ForteScarlet
Copy link
Owner

Added an annotation for function positioning in K2: TargetMarker .

It is defined in the annotation module and can be customised through configuration item targetMarker.

suspendTransform {
    targetMarker = ClassInfo(...)
}

What it does

Previously, in K2 mode, to generate a bridge function for a pending function, you needed to generate the symbol of the bridge function in the FIR stage and then generate the Body of the bridge function in the IR stage.

In the IR stage I need to know who the source function corresponding to the bridge function is.
But the source function is located in the FIR stage, so we need to pass some uniquely located information about the source function with the help of PluginKey, which includes its function name and a list of the parameter types. (I haven't found a safe, direct way to determine whether FIR and IR are the same by using ==)

Previously, this solution was basically possible because the function name and the list of types could identify a unique function.

But this does not work in the case of #72.

The combination of expect/actual and typealias is used in #72. At the FIR stage, the MoneyValue is always MoneyValue type, and since it's expected, I've never been able to find out how to get its real type, whether it's actual or typealias. I tried a number of ways, such as expectForActual, memberExpectForActual, fullyExpandedType, and other seemingly related functions I could find. But they either get MoneyValue itself or null, there is no available solution.
As for other options, after all, KCP is not fully documented and I can't get started at the moment.

And after the FIR, in the IR stage, MoneyValue has completely changed to BigDecimal, which is why it is impossible to locate the source function: the FIR stage and the IR stage, the same function has a different parameter type.

FIR match IR
errorReproduction ---✔--- errorReproduction
\- [0]MoneyValue ---❓--- \- [0]java.math.BigDecimal

How to fix

Rather than fixing it, I think it's more like circumventing the problem outright. Since I can't locate the source function via the argument type list, I'll just locate it in a different way.

The new annotation TargetMarket does just that. In the FIR stage, a unique ID is generated from the function name and the list of parameter types (that's the base64 string with the name and type spliced in order)

Mark this ID and annotation on the source function. Then, only this ID is passed to the IR, not the list of types. Afterwards, in the IR stage, only the function with a matching value needs to be found.

FIR ID match ID to look for IR
errorReproduction(MoneyValue) abcd1234 ---✔--- abcd1234 errorReproduction(BigDecimal)

caution

By default, targetMarker is specified as an annotation TargetMarker in the annotation module.
When the targetMarker annotation is specified, there will be no matching based on other ways. So please note that if you customise an targetMarker annotation and it is not available, or if you disable references to the annotation module (includeAnnotation = false), this may cause problems.

If you specify targetMarker as null, then the matching is done using the original scheme: using the function name and argument type list.

suspendTransform {
    targetMarker = null
}

It's not clear to me at the moment if there's a better solution to the problem of finding some function from IR that is identified in FIR, or to the problem of expect/actual+typealias.

resolve #72

@ForteScarlet ForteScarlet added bug Something isn't working enhancement New feature or request labels Dec 21, 2024
@ForteScarlet ForteScarlet merged commit 1e38b25 into dev Dec 21, 2024
1 check passed
@ForteScarlet ForteScarlet deleted the fix-72 branch December 21, 2024 06:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error generating JVM code for function with typealias argument
1 participant