When we generate call for 'foo', we make decision about invoking
a 'foo$default' too late, after the call arguments are generated.
If 'foo' was an override, and base class (interface) was generic,
'foo' in base class could have a different Kotlin and JVM
signature, so the arguments we generated could be generated wrong
(primitive or inline class values instead of boxes, see KT-38680).
Also, we always selected first base class in supertypes list,
which caused KT-15971.
Look into resolved call and see if we should actually call
'foo$default' instead of 'foo' when determining actual callable.
Overrides can't introduce default parameter values, and
override-equivalent inherited methods with default parameters
is an error in a child class. Thus, if we are calling a class
member function with a default parameters, there should be one
and only one overridden function that has default parameter values
and overrides nothing.
- To fix this test `ExpectActualTable` has to be refactored from usage
of descriptors to IdSignature since Wrapped and Deserialized descriptors
for the same declaration are not equal to each other.
Also:
* Do not rename public ABI fields
This includes backing fields for const, lateinit, @JvmField properties,
and instance fields for objects.
* FAKE_OVERRIDE declarations for static members of parent Java classes
Required to report cases when a Kotlin function accidentally overrides
Java class member.
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
Quoted from https://kotlinlang.org/docs/reference/classes.html
"On the JVM, if all of the parameters of the primary constructor have
default values, the compiler will generate an additional parameterless
constructor which will use the default values. This makes it easier to
use Kotlin with libraries such as Jackson or JPA that create class
instances through parameterless constructors."
Two known issues with generateNonPartClassDeclarations that was here
before were the fact that we didn't sort sealed classes and its
subclasses which led to NoSuchMethodError (KT-27097), and the fact that
we didn't skip expect classes which led to incorrect duplicate JVM class
name diagnostic (KT-30843)
#KT-27097 Fixed
#KT-30843 Fixed
Proper SMAP support for default values from expect declarations is required.
Default value in expect declaration could has line number that
exceed line count in actual file that causes an error
#KT-23739 Fixed
#KT-29174 Open
* Copy lowering from konan to common
* Keep actual default parameters when both actual and expect default parameters are present
* Run lowering before inline in JS IR BE to fix
box/multiplatform/defaultArguments/inlineFunctionWithDefaultLambda.kt
It's difficult to fix KT-22818 until the IR comes along, so we're
providing a workaround where one can disable the
ACTUAL_FUNCTION_WITH_DEFAULT_ARGUMENTS error and provide default values
in the actual function, to avoid exception from the backend.
#KT-22818
* Move FinallyBlockLowering to common part
* Fix catching of dynamic exception
* Fix bridges for suspend functions
* Disable explicit cast to Unit
* Run lowering per module
* Update some test data
After this change, optional expected annotations will be compiled to
physical class files on JVM, and stored to metadata on other platforms,
to allow their usages from dependent platform modules. For example:
@OptionalExpectation
expect annotation class A
When compiling this code on JVM, A.class will be produced as if the
class A did neither have the 'expect' modifier, nor had it been
annotated with OptionalExpectation. Note that if there's no actual
annotation class for A, then usages (which can only be usages as
annotation entries) are simply skipped.
Class A will be public from Kotlin's point of view (since it should
be possible to use it in Kotlin sources), but _package-private_ in Java
to disallow its usages outside of the declaring module.
#KT-18882 Fixed
#KT-24617 Fixed
MPP-related:
* inherited from interfaces
* inherited body from interface
* default arguments in an interface, implemented by a class delegate
* super call of a method with default argument
Also:
* inheritance from an interface and another interface descendant (KT-21968)
* inheritance through an intermediate interface
This commits adds a new annotation OptionalExpectation to the standard
library, which is experimental. To enable its usage, either pass
'-Xuse-experimental=kotlin.ExperimentalMultiplatform' as a compiler
argument, or '-Xuse-experimental=kotlin.Experimental' and also annotate
each usage with `@UseExperimental(ExperimentalMultiplatform::class)`
#KT-18882 Fixed
`countDefaultParameters` uses `hasDefaultValue` to compute the number of
parameters which have default values, which handles actual parameters
(who have default values in the expected declaration) correctly. Thus,
`getRemainingParameters` should use it as well to determine the list of
parameters to be skipped in each generated overload
#KT-23910 Fixed
When a parameter has a default argument value both in the expected
annotation and in the actual annotation, they must be equal. This check
has been only implemented for the case when actual annotation is Kotlin
source code, and NOT a Java class coming from an actual typealias. The
latter case would require a bit more work in passing a platform-specific
annotation-value-reading component to ExpectedActualDeclarationChecker,
and is therefore postponed.
For now, Java annotations that are visible through actual type aliases
cannot have default argument values for parameters which already have
default values in the expected annotation declaration
#KT-22703 Fixed
#KT-22704 Open
Jinseong Jeon