When an inline lambda is invoked or passed to another inline function,
make sure non-local returns are allowed by all surrounding declarations.
Otherwise, NON_LOCAL_RETURN_NOT_ALLOWED must be reported.
^KT-59884 Fixed
^KT-55319 Fixed
These tests are mostly used to check ABI in case you're compiling a
library or library-like code, which is no longer possible (since old JVM
backend is only used in the IDE).
Mute them for the old JVM backend instead. JVM IR behavior is fine in
all cases except maybe `destructured.kt`, for which there's now an issue
KT-63075.
Track changes in K/N stubs directly instead of using the hack with
KlibMetaFileType.STUB_VERSION + KotlinStubVersions.BUILTIN_STUB_VERSION.
Changes in built-in stubs might or might not affect .knm stubs and
should be tracked independently.
The used offset constant for migration is the sum of the offsets from
KlibMetaFileType and KotlinStubVersions.BUILTIN_STUB_VERSION.
KTIJ-26761
KTIJ-26961
Annotation loaders for descriptors (AnnotationAndConstantLoaderImpl) and
stubs (AnnotationLoaderForStubBuilderImpl) share the loading logic until
mapping ProtoBuf.Annotations to output values. The shared logic has been
extracted to the base class.
KTIJ-26761
KTIJ-26961
Add annotation loading for property backing field, property delegate and
extension receiver to AnnotationLoaderForStubBuilderImpl. Use logic from
AnnotationAndConstantLoaderImpl.
AnnotationLoaderForStubBuilderImpl is used by KotlinMetadataDecompiler,
K2KlibMetadataDecompiler and KotlinJavaScriptMetaFileDecompiler. Stub
versions for built-ins (affects metadata and K/N decompilers) and JS
are bumped.
KTIJ-26761
KTIJ-26961
With "-nopack" compiler option, it is possible to build unzipped klibs.
This makes it possible to get rid of install tasks that unzip them.
Also, an obsolete test for klib installation was removed.
`stickyPostconditions` are such conditions that are checked
every time after applying when a new lowering finishes its execution.
Right now we are using them only in JVM, and this is a blocker
for adopting Native approach for lowering execution.
In Native we are using
`SimpleNamedCompilerPhase<in Context : LoggingContext, Input, Output>`
as the common super type for all lowerings. Here we have `Input` and
`Output` that can potentially be different and `stickyPostconditions`
don't have much sense in that case.
`resolveDependencies` showed up as a hotspot when profiling due to `canonicalPath` doing a lot of file system calls.
`fileKey` is more efficient and should guarantee uniqueness (`canonicalPath` may fail in the case of hardlinks).
The new code is 3x faster in our use case.
This class should contain 'global' settings for reference shortening;
ATM it only contains the `removeThis` flag
In the future this setting might be merged together with
`ShortenStrategy` to be computed on per-element basis
- Since this documentation was written, the usages of contextual modules
have expanded beyond outsider files, for example to support `KtModule`
disambiguation for library elements. Hence, it was necessary to update
the documentation accordingly.
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
Before this commit, we first tried to guess a type of array literal
in deserialized annotation (it's a strange heuristics which can
lead to SOE and maybe not needed at all, see KT-62598, KT-62929),
and then, if unsuccessful, took the type from the first literal element,
if any. Since the second heuristic is much more clear, safe, and
understandable, in this commit they were swapped.
This commit does not fix KT-62598 in general case,
but decreases a set of cases when it can occur to
empty array literals only.
See the commented line at the end of the added test.
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
Since they are not `FirSmartCastExpression`s,
they are treated as proper original types,
thus leading to reporting errors instead of
warnings.
^KT-60095 Fixed
Brian Norman