same as they were in K1 (see KSerializerDescriptorResolver): internal for
final classes and public for non-final.
Unfortunately, there are no Klib API dumps tests in the compiler, so I tested manually.
#KT-64124 Fixed
for cases when the version requirement cannot be read correctly (missing from the table).
It usually happens when we read the inner class' old metadata, which stored everything
in the outer class' table.
Fixes #KT-60870
Merge-request: KT-MR-13337
Merged-by: Leonid Startsev <leonid.startsev@jetbrains.com>
Swift Export Frontend generates a Kotlin file/library that contains a
set of simple bridging functions that connect Swift wrappers to their
Kotlin counterparts.
There are certain requirements for these wrappers:
1. They should not be DCEd when compiling a binary library.
In other words, these functions are roots.
2. They should provide a stable simple binary name.
3. Their signatures should be much simpler and restricted comparing to
other Kotlin functions.
Altogether, these requirements should be covered by introducing the new
ExportedBridge annotation.
Note: Frontend checks of ExportedBridge functions are not implemented
yet.
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
Ilya Chernikov