After discussions, "Kotlin Apple Ecosystem" team agreed to take
responsibility for the Commonizer tool.
P.s. integration between Commonizer and Gradle is responsibility of
the "Kotlin Build Tools" team.
They were accidentally fixed with `[FIR] Process all overridden members from intersection scopes`
commit, which itself introduced incorrect behavior, which was properly
fixed with ... commit. So KT-64081 started to appear again
Previously, there was a contract that each callable symbol in the chain
of `processDirectOverriddenWithBaseScope` will be unique. And if some
symbol is accessible from multiple scopes, then only last of them will
be returned as a component of `MemberWithScope`. So there actually was
no such thing as "pair of two different MemberWithScope with the same
symbol and different scopes"
After the change of `processDirectOverriddenWithBaseScope` contract (see
previous commits) each scope returns `MemberWithScope` for some symbol
with the previous scope in the hierarchy even if it contains the same
symbol as the current scope
So now scope is actually a part of `MemberWithScope`, which should be
considered as part of equality. Otherwise, we can skip some part of
the overridden hierarchy, because we will start to consider symbol as
visited after its first occurrence (in opposite to the previous behavior,
when only the last scope was returned)
Previously, there was a contract that each callable symbol in the chain
of `processDirectOverriddenWithBaseScope` will be unique. And if some
symbol is accessible from multiple scopes, then only last of them will
be returned as a component of `MemberWithScope`
But after the change from previous commit, we don't have this contract anymore.
Which means that we may meet the same symbol during processing hierarchy
of overridden functions (but with different base scopes)
So if some code utilizes `process...Overridden...WithBaseScope` functions
it should consider that the same symbol may be obtained several times
^KT-63738 Fixed
Kotlin code for Objective-C interop is always included to stdlib.
It depends on some C++ code. The latter is compiled conditionally -
only for targets supporting Objective-C interop. That might cause
undefined symbols problems when DCE is not enabled.
To deal with it, we usually have trivial stubs in C++ code, used
for targets not supporting Objective-C interop.
This commit adds a couple of such missing stubs.
In case of HMPP structure with common JVM module (e.g. shared between
JVM and Android) one can reference the same field from java code,
so it should be shared between fir2ir sessions
^KT-63574 Fixed
This bug spilled into reference shortener, and then to
"redundant qualifier inspection" and code completion from there;
it caused KTIJ-26024 to reproduce again (but only for anonymous objects)
^KT-64186 Fixed
The entire concept of conventions is deprecated in Gradle. Here it was making the build logic implicit and hard for understanding
^KTI-1473 In Progress
The entire concept of conventions is deprecated in Gradle. The proposed alternative for `BasePluginConvention` is `BasePluginExtension`
^KTI-1473 In Progress
It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
Dmitrii Gridin