Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
* Caches are compared as files now. It is a more robust approach
than comparing strings with dumped contents. E.g previous test
ignored differences in keys ordering, because dumping caches to string
was added for comparing caches after incremental and non-incremental builds,
which cannot be compared without sorting keys (see KT-32674).
* Calling setUp/tearDown twice within the same test instance was
relatively hacky and fragile. Also it complicated adding new test cases.
Lookup storage output files could differ for projects
with different absolute paths.
This happened because, paths for lookups were
relativized only before writing to the underlying storage.
Storing absolute paths in a hash table could
result in different order of adding files to the lookup storage.
This commit fixes the issue by sorting lookups and files in
LookupStorage#addAll
#KT-32674 Fixed
Our JPS and Gradle plugins handle
recompilation of multifile classes differently.
JPS plugin delegates handling to the JPS itself,
which tracks dependencies via bytecode,
and marks classes as dirty when they are affected.
So in JPS other parts of multifile classes are recompiled only
when a part's signature is changed.
In Gradle plugin we handle recompilation ourselves in
simpler way: any change in any part leads to a recompilation
of all parts of the same multifile class.
In future we should improve our Gradle plugin, but for now
I'm changing the test so that both JPS and Gradle tests
recompile all parts.
Also the dummy function is added to make sure that we
don't blindly recompile everything when a part is changed.
JVM compiler loads scripting plugin by default,
which in turn performs script template discovery
in compile classpath.
Classloading and template discovery takes noticeable
amount of time in JPS tests, because of
relatively big number of short compilations.
Disabling scripting plugin in most JPS+JVM tests
speeds up JPS tests by ~8% compared to the result before all
optimizations.
This speeds up JPS tests by ~16% compared to the result before all
optimizations. The speedup comes mostly from avoiding re-reading jar
files (like kotlin-stdlib.jar).
After each test we rebuild everything,
then we compare incremental caches and output
with caches and output after rebuild.
For some reason we did rebuild and comparison
twice per test. This seems excessive.
Removing the second rebuild speeds up JPS tests by ~15%
compared to the result before all optimizations
Pavel Kirpichenkov