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
Original commit: 2d598d50d7
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.
Original commit: 8c52bb4212
- Use 'null' as indicator of non-MPP version. Consequently, remove
useless 'isMpp' method, and lift all methods to extensions (to be able
to call them on nullable 'facetSettings.mppVersion')
- Change semantics of extensions to check for exact equality rather than
for "at least specified version"
- Deprecate old MPP-versioning in favour of 'facetSettings.mppVersion'
Original commit: 958a7d9315
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.
Original commit: 4be0e00071
* 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.
Original commit: afa10cc125
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
Original commit: a4c62d156f
It works incorrectly for cases of non-trivial common platforms (works
fine for 'JVM/JS/Native', but doesn't work for 'JVM/JS')
Original commit: d458821565
Alexey Tsvetkov