Collect module name properly from facets settings, using CLI arguments
which define module name ('-module-name' on JVM and Common,
'-output-file' on JS).
^KT-23668 Fixed
because source-based LightAnnotations produces annotation values from arguments in sources even when they are invalid as parameters. Thus they could be inconsistenct with "compiled" ones and it is not an error.
- Use direct access to property defined into companion object when
it is possible rather than always use an accessor to access the
property.
- Use direct access will speedup runtime performance.
- Avoid to generate useless accessors for companion properties.
Fix of https://youtrack.jetbrains.com/issue/KT-14258
Fix generating multifile facade with all members private (in bytecode)
leading to delegate not being generated for corresponding light class
#KT-20966 Fixed
Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
Allow to get annotation list and to invoke `findAnnotation` without building delegate
Introduce KtLightNullabilityAnnotation which holds nullability information and is built
before delegate is built
To provide consistency between light classes and their delegates
IdeLightClass#testExtendingInterfaceWithDefaultImpls still failing since
we do not generate implementations delegating to DefaultImpls of superinterfaces
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
See 4a533168d9 for the original change which
introduced the problem
Note that the added test case _was not failing_ before the change. It's added
because there were no tests on multi-file class behavior in light classes mode
at all. The actual repro for the problem is difficult to make a test from
#KT-12755 Fixed
Mikhael Bogdanov