This is a proposal to fix KT-49364.
Operand stack type verification happens before `checkcast`
is executed. When we implicitly cast an inline class
to a non-inline type, if type of stack value is not subtype
of the target, then coercing is necessary.
It helps to:
- keep declarations even if they are not reachable and not exported
- not minify names of not exported declarations
Compiler argument: -Xir-keep=A,B
Can be used for top-level declarations or for member
^KT-54118 fixed
Old one is deprecated and delegates to new options. All new options
are marked with task input types, so they could be used as `@Nested`
input.
Generated options are using specific types in generated
compiler options. This should simplify code completion and provide
meaningful hints to user.
At this point repository compilation will fail.
^KT-27301 In Progress
Problem: ClasspathChangesComputer (a core component of the new IC) uses
the existing inline function analysis from the old IC
(IncrementalJvmCache.InlineFunctionsMap). If an inline property accessor
has changed, the inline function analysis will report the name of the
property accessor, not the name of the property.
ClasspathChangesComputer doesn't see the property accessor's name in the
list of class/package members, so it will throw an exception.
Solution: There are 2 options:
1. If an inline property accessor has changed, the inline function
analysis can report the name of the property instead of the
property accessor.
2. ClasspathChangesComputer can include property accessors in the list
of class/package members.
In this commit, we will choose option 2 as it is simpler.
Test: New KotlinOnlyClasspathChangesComputerTest.testPropertyAccessors
Small cleanup - PLS SQUASH INTO PREVIOUS COMMIT
- Address review
- Fix failed tests
- Add some trivial changes
^KT-53871 Fixed
Make it clear that there 3 distinct cases:
1. Incremental compilation completed with an ExitCode.
2. Incremental compilation was not possible for some valid reason
(e.g., for a clean build), and we will perform non-incremental
compilation.
3. Incremental compilation failed with an exception.
In this case, we will:
- Print a warning with a stack trace
- Ask the user to file a bug
- Collect rebuild reason enum for analytics
+ TODO: Collect the stack trace too
- Fall back to non-incremental compilation
Test: Existing BaseIncrementalCompilationMultiProjectIT.testFailureHandling_UserError,
Updated BaseIncrementalCompilationMultiProjectIT.testFailureHandling_ToolError
^KT-53015: In progress
For non-suspend lambdas annotations are carried over to the
invoke method so that tooling can find the annotation there.
It seems reasonable that annotations are carried over to
the invokeSuspend method on suspend lambdas as well so that
similar tooling can be built and work for suspend lambdas.
When suspend function type is serialized, there is special logic that
adds Continuation parameter, before doing so, type-aliases has to be
expanded, attributes for resulting type should also derive from
expanded type
KT-53193, KT-54062
Disable it if we do not have required `noCompiledSerializer` function in
runtime. Leave it enabled in tests.
Rollback some changes for old backend as it is unsupported now.
instead, plugins should emit the code similar to the TYPE_OF one with
a special call to MagicApiIntrinsics.voidMagicApiCall directly afterwards.
This is required because old compiler need to correctly inline code
rewritten by plugin.
Add intrinsic for kotlinx.serialization.serializer<T>() function.
Plugin intrinsic for old backend is removed because it is too hard
and unjustifiable to unify them.
(Old is created first because all intrinsics emit bytecode anyway)
Provide intrinsic for serializer<T>() function so it won't
invoke typeOf() construction and KType->KSerializer conversion
making it fast and truly reflectionless
Add support for recalculating stack size in plugin-defined intrinsics
since it is needed for correct work:
Unify method for recalculating stack size with existing typeOf intrinsic
Add testdata for IR for future intrinsic in IR
- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
Example: if C is a Kotlin class and there is an import of C.Companion.f,
a call to f will need to check if it is a constructor, for which
it will attempt to load C.Companion.f as a Java class. This involves
loading all outer classes, including C itself, as BinaryJavaClass - see
KotlinCliJavaFileManagerImpl - despite the fact that C and C.Companion
have both already been loaded from their Metadata annotations as Kotlin
classes, wasting cycles and polluting caches.
Thus the theoretical motivation for this change is to marginally speed
up FIR.
The real motivation is that with the -Xemit-jvm-type-annotations option,
kotlinc sometimes generates invalid annotations, and reading them with
BinaryJavaClass throws an exception (the Kotlin metadata however is
valid):
// MODULE: lib
// FILE: C.kt
// The constructor has an argument of type
// List<? extends Function1<? super String, Integer>>
// and a ParameterName type annotation with path
// TYPE_ARGUMENT(0), TYPE_ARGUMENT(0)
// which is missing a WILDCARD between the two TYPE_ARGUMENTs
class C(val x: List<(name: String) -> Int>) {
companion object {
fun foo() {}
}
}
// MODULE: main(lib)
// FILE: main.kt
import C.Companion.f
fun bar() = foo() // crashes FIR
The parameter annotation should obviously be fixed too, but invalid
bytecode may already exist in the wild. Also, did I mention that this
change marginally speeds up FIR?
JS IR generates bridges with type checks for special class methods,
however if parent and child type parameters are same,
the JS signature for the generated brige will be clashed with
the JS signature of original method.
This patch changes type parameter name of EnumEntriesList to avoid the clash.
^KT-54011 Fixed
Ilmir Usmanov