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
