We can reuse existing static/dynamic library output kinds for
the Swift Export. The only change we have to make is to make generation
of C interface opt-out by moving it under the binary option.
As a side effect, it allows evolving C Export in the future by
introducing new option variants.
It fixes the exception when REPL is run on an ARM Mac, as well as not
quitting after interrupting on the first line.
After this change, REPL runs fine on JDK 8, 17, 21. Note that on JDK 11,
it prints a warning during startup (but then also runs fine):
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jline.terminal.impl.exec.ExecTerminalProvider$ReflectionRedirectPipeCreator to constructor java.lang.ProcessBuilder$RedirectPipeImpl()
WARNING: Please consider reporting this to the maintainers of org.jline.terminal.impl.exec.ExecTerminalProvider$ReflectionRedirectPipeCreator
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
#KT-18355 Fixed
#KT-64013 Fixed
Api which previously used buildDirectory now migrated to Provider as well, previous properties are deprecated.
^KT-61294 fixed
Co-authored-by: Alexander Likhachev <Alexander.Likhachev@jetbrains.com>
Those fields were effectively marked as child elements after refactor.
However, because of the current (to possibly be changed) configuration,
the generator did not write accept methods for them.
This problem is extensively described in
`cadbc87dfd1ce3e63481ab90874ca8858878c55f` commit message.
TLDR: compiler is also called from Android LiveEdit plugin where
we want to be able to use compiler plugins. For that reason, we have two
different flags in the compiler. One is only for "evaluate expression"
(`doNotLoadDependencyModuleHeaders`) and the other for both LiveEdit
plugin and "evaluate expression" (`shouldStubAndNotLinkUnboundSymbols)`.
We want to forbid using compiler extensions for "evaluate expression"
and allow for LiveEdit plugin.
#KT-63695
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
Sergey Bogolepov