Previously we prohibited classes and properties with the same name (now it's unnecessary)
Add test for backends that they support qualified (by default object name) member references inside class body
Star-projections have upper bounds of the form "parameter's bound where all parameter of the same class are substituted with their star-projections"
#KT-6803 Fixed
- It's worked almost fine but diagnostics were filtered out by
positioning strategy.
- Also a couple of "put" calls to Multimap are replaced by "putValues"
within OverloadResolver, that is more semantically correct.
- Note that constructors of top-level classes are handled when processing
package, it helps to figure out if there are clashes with top-level
functions that have the same name.
- But constructors of different classes are not reported as
overloads because containing classes has the same name and will be
reported as redeclaration.
It's need to add synthetic argument (of type that user can't use)
to constructors with default arguments to avoid clashing with
real user's constructor having the same set of parameters
and additional int's arguments.
There is a lot of changes about closures calculating and generating.
1. As classes can have more than one constructor each of them should
have closure arguments.
2. Captured variables set is the same for all of them.
3. Within constructors bodies/delegating calls closure parameters
should be accessed through method arguments because fields may be
not initialized yet.
When deal with constructed object (not this) treat it like it's fully initialized.
Otherwise (this or access with no receiver) access instruction
should be handled as it was before.
#KT-6788 Fixed
#KT-4126 Fixed
- use ConcurrentHashMap as a cache of class loaders to module descriptors
- KClassImpl now has a lazy class descriptor and it manages property creation
by looking (also lazily) for the property descriptor in the corresponding
scope
- since deserialized descriptors have full information about where a JVM symbol
is located and what signature it has, new tests will begin to pass where
Kotlin model and Java reflection model differ, see classObjectVar.kt
Reflection will be distributed in a separate jar and not in kotlin-runtime.jar
for two primary reasons:
- Reflection implementation at the moment takes almost 2Mb
- Separate libraries for separate features is a technique encouraged by Maven,
and it's inconvenient to make it different in the compiler distribution
Nikolay Krasko