Before this commit, K2 always applied coercion-to-unit for
callable references if expected type was Unit, and actual non-Unit.
However, this may not work in case when actual return type is
a type parameter and it must be inferred into Unit.
In this commit we started to disallow coercion-to-unit
for references with synthetic outer call (~ top-level in K1)
AND a type parameter as a return type (both should be true to disallow).
This provides better K1 consistency,
while still keeping some broken K1 cases working in K2.
See also added comment in CallableReferenceResolution.kt.
#KT-62565 Fixed
- See KT-63718 for a detailed description of the issue. This fix is a
workaround (see KT-64236).
- It's worth mentioning that it's too expensive to compute package sets
for "all libraries except one". Package sets are just an optimization.
^KT-63718 fixed
This corrects the type given to GEP2 when initializing a stacklocal
array. This issue only cause problems when bitcode gets written before
any of the optimization passes, in which case it will fail on LLVM
validation when reading the bitcode back in on a subsequent pass.
(reuse anonymous initializers as block wrappers) so the top-level script
elements are all declarations now. Rename the property accordingly (
together with the previous commit).
It makes script more similar to the class and thus simplify e.g.
control flow analysis and resolve code.
rename them since they generate variables with initialization, rather
than arbitrary statements, and this fact is used in scripts
and also add initialization helper, used for scripting support too.
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
Mikhail Glukhikh