Preserve static initialization semantics for parts by introducing a special "clinit trigger" class.
Insert "static initialization trigger" call to every method of a part class, remove this call on inline.
Always mangle names for private functions in multifile class parts to avoid resolution clashes on inheritance.
NB in codegen tests initializers for all non-const vals are wrapped in 'run { ... }',
so that the initializer is not a constant expression, and some static initialization code should be generated.
Although a test is present, it doesn't check the behavior because it seems that
in the test environment both streams are necessarily flushed
#KT-9546 Fixed
Rework backing field generation logic in PropertyCodegen to switch the
ClassBuilder instance for a multifile part to that of the corresponding facade
class. This became needed because multifile parts, and their metadata, are
generated _before_ the multifile facade class and otherwise we would never
record that there's a synthetic '$annotations' method for a const val and would
not write that to the protobuf message for the property.
See also bad83200
#KT-10892 Fixed
Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Technically we often can compile code which uses missing classes (as long as
nothing is called on them) but it seems better to let the user know something's
wrong in their setup before the error manifests itself at runtime. Also the
Java compiler does the same
#KT-4328 Fixed
For a class which cannot be resolved in the current deserialization session,
create a special ClassDescriptor instance with an empty scope and put in the
correct package under the current module. Codegen will perfectly map such class
to its JVM signature (because only the precise FQ name is needed, which is
available). For more details on this approach, see the issue description.
#KT-4328 Fixed
#KT-11497 Fixed
Do not use MockLibraryUtil to compile Kotlin code: this allows to avoid
rebuilding kotlin-compiler.jar every time before running a test. Also extract a
few utilities, use Kotlin stdlib where possible
Protected should be translated to public as in Java so that everything would
work at runtime. The real visibility is still saved to an InnerClasses
attribute
#KT-8269 Fixed
#KT-9246 Fixed
#KT-10143 Fixed
The commit was done by @yole in assumption that the function only affects PARF lines generated by compiler, but similar lines generated
by daemon infrastructure were affected as well, the mentioned test was failing since. CliBaseTest class was refactored, I place the removePerfOutput
function into AbstractCliTest class.
Load immutable flexible upper bound for 'Iterable<? super T>'
We load 'Collection<? super CharSequence>' as 'MutableCollection<in CharSequence>'
instead of 'MutableCollection<in CharSequence>..Collection<*>'
because it's obviously not typesafe to use any 'Collection<*>'
as argument for such type.
But there'se nothing bad with loading 'Iterable<? super CharSequence>'
as 'MutableIterable<*>..Collection<*>'. Same for other declarations that have
covariant mutable representation (currently Iterator, ListIterator).
Also there are useful use-cases when it's neccessary to use 'Iterable<*>'
as an argument for parameter with type 'Iterable<? super T>' (see matchers.kt test).
NB: Star-projections appear in examples because types like 'Collection<in CharSequence>'
with conflicting use-site projections are invalid in Kotlin, but they are valid in Java.
Nikolay Krasko