When the enum entry requires a specific class, its constructor should
invoke proper supertype constructor (from the corresponding enum class).
Corresponding resolved call should be passed from the front-end in
CONSTRUCTOR_RESOLVED_DELEGATION_CALL slice.
In case of enum entries without explicit supertype initializer, this
information was missing.
Given a singleton class 'S' with possibly uninitialized static instance
(enum entry, interface companion object).
Such singleton can be referenced by name, or as an explicit or implicit
'this'.
For a given singleton class 'S' we
either use 'this@S' from context (local or captured),
or 'S' as a static instance.
Local or captured 'this@S' should be used if:
- we are in the constructor for 'S',
and corresponding instance is initialized
by super or delegating constructor call;
- we are in any other member of 'S' or any of its inner classes.
Otherwise, a static instance should be used.
Singleton instance is "initialized" by delegating constructor call,
which is superclass constructor call in case of singletons (because
singletons can't have more than one constructor).
Singleton constructor is effectively split into two stages:
- before a super constructor call;
- after a super constructor call.
Before super constructor call, singleton instance can't be used directly
(see KT-20662), because neither 'this' nor static instance is
initialized yet. However, it can be used in closures, in which case a
static instance should be used (escaping uninitialized this is
prohibited by JVM). Actually using this static instance before it is
initialized (e.g., invoking a method that uses this singleton) will
cause a correct ExceptionInInitializerError.
After a super constructor call, static instance of a singleton may be
not initialized yet (in case of enum entries and interface companion
objects). However, we already have an initialized 'this', which we
should use for singleton references.
#KT-20651 Fixed
Enum entries are "special" kind of singletons that should be
referenced as a captured 'this' instance inside during entry
initialization, because corresponding static fields in enum class
are not initialized yet.
#KT-7257 Fixed
In an inner class of the enum entry class, enum entry reference should
be generated as an outer 'this', not as a enum entry access, because
enum entry itself may be not initialized yet.
Make enum entries initialize before companion object. This helps
in situation when companion object initializer refers to enum fields.
JVM be generates <clinit> method which first initializes all enum fields
and then runs companion object initializer. This commit introduces the
similar behaviour in JS BE. The old behaviour was: initialize companion
object in constructor. In enum, constructor is called to initialize
enum fields, so previously companion object was initialized first,
which is incorrect.
See KT-16745
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
The problem was that he number of mask parameters for defaults when
generating methods declaration was being calculated upon resulting signature
(with additional parameters: extension receivers, enum name/ordinal),
while on call-sites the masks number was calculated by the arguments number
in resolved call, i.e. by the number of real value parameters.
And because of the additional synthetic parameters (like enum.ordinal) these
two numbers could be different.
The solution is just to use value parameters number in both places.
Note, that we only count value parameters from the original sourse
declaration, ignoring synthetic ones generated by backend (e.g.
Continuation for suspend functions)
#KT-14565 Fixed
Do not report an error on enum entry without initializer if all parameters have default values
(error is still reported if there is no such constructor, or if the constructor call is ambiguous).
Record resolved call on KtEnumEntry.
NB is the enum entry has a corresponding subclass, we still have to generate the "default" constructor call,
because FE doesn't know about the platform-specific representation of that class and its constructors.
See also KT-14097, KT-15900
Grammar changed accordingly.
Semicolons prohibited after an entry except the last one.
Only one initializer is allowed per entry.
EnumReferenceExpression AST node introduced.
Some tests fixed, a pair of new tests written. Kotlin code inside project fixed.
Formatter and intendation tests fixed accordingly.
Stub version is incremented.
The fqname of class should be clear from code
Example: can't shorten A.Default.B.Default.C to A.B.C
Also fixes problem when nested class of enum class could be accessed via enum entry
#KT-5402 Fixed
#KT-4838 Fixed
Resolve type of object inside local object as special, not supertype('Any').
Changed visibility of constructor of anonymous object to 'internal' to be able to resolve the following:
fun box(): String {
var foo = object {
val bar = object {
val baz = "ok"
}
}
return foo.bar.baz
}
The containing declaration of property initializers is constructor, so 'baz' was invisible inside private constructor.
- inline asmType to calling getAsmType, which does something more
- refactor getJvmInternalName to use getAsmType as well
- simplify getAsmType and fix a probable bug in mapping singletons nested in
enums (which wasn't reproduced, though a test is added)
- delete unnnecessary ASM_TYPE recording for enum entries in
CodegenAnnotatingVisitor
