Sometimes IC raises compilation errors when rebuild succeeds.
This happens because IC uses serialized decriptors
for non-dirty files. Serialized descriptors can be different
from source file descriptors. For example, a source file
may contain an implicit return type or an implicit visibility
for overridden methods, but serialized descriptors always
contain explicit return types & methods' visibilities.
These problems can be solved by expanding a scope of incremental compilation
just after the analysis, but before error reporting & code generation.
In other words, we need to compare descriptors before error reporting and code generation.
If there are new dirty files, current round of IC must be aborted,
next round must be performed with new dirty files.
This commit implements IC scope expansion for JS Klib compiler
#KT-13677
#KT-28233
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.
Alexey Tsvetkov