Skip to content

Fix: An int argument picks the overload its Kotlin literal would - #156

Merged
b-re-w merged 1 commit into
developfrom
feat/int-literal-overload
Oct 3, 2026
Merged

b-re-w merged 1 commit into
developfrom
feat/int-literal-overload

Conversation

@b-re-w

@b-re-w b-re-w commented Oct 3, 2026

Copy link
Copy Markdown
Member

Closes #146

Defect fixed: an integral slot accepted any int (an Int slot took 2**31), and an int that fit two overloads' integral slots was refused as ambiguous. Now an int reaches an integral slot only inside that Kotlin type's range, and a remaining tie goes to the overload whose integral slots match each int's Kotlin literal type (Int if it fits in 32 bits, else Long), as kotlinc resolves Color(0xFFFFFFFF) to Color(Long).

Test added: PythonxAdapterTest.anIntArgumentPicksTheOverloadItsKotlinLiteralWould, with Color__Int/Color__Long in ComposeShapedFragment. Red before the fix (18 run, 1 failed).
Spec: SPEC U-8.

Verified locally, each module separately: plugin test 274/0, desktopTest 608/0, artifact 35/0, app 79/0, compose 118 with 1 failure in the first run (aCounterDeclaredAsMutableStateOfZeroAndIncrementedFromPythonRecomposes, the known intermittent one, also seen on develop), then 3 of 3 reruns green; androidNative compile OK.

An integral slot takes an int only inside its Kotlin type's range, and a tie
between overloads goes to the one whose integral slots match each int's literal
type (Int if it fits in 32 bits, else Long), as kotlinc resolves
Color(0xFFFFFFFF) to Color(Long). Red before the change:
anIntArgumentPicksTheOverloadItsKotlinLiteralWould failed (18 run, 1 failed).
@b-re-w
b-re-w merged commit a8de4c4 into develop Oct 3, 2026
5 checks passed
@b-re-w
b-re-w deleted the feat/int-literal-overload branch October 3, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant