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
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.
Original commit: 7f1d30058a
Previously, a lot of clients used JvmPlatform as platform-marker,
without thinking about jvmTarget.
For the sake of migration, this commits introduced so-called
UnspecifiedJvmPlatform, which can be used for a time being, but
generally, all usages should be removed in future.
Original commit: 8997fa52df
This is a large commit, which introduces general API for working with
abstraction of Platform.
- Add new abstraction to 'core' - SimplePlatform - which represents
exactly one platform
- Clients are strongly prohibited to create instances of SimplePlatform
by hand, instead, corresponding *Platforms abstraction should be used
(e.g. JvmPlatforms, JsPlatforms, KonanPlatforms)
- Move TargetPlatform to 'core', it represents now a collection of
SimplePlatforms
- Clients are strongly encouraged to use TargetPlatform
(not SimplePlatform) in API, to enforce checks for multiplatform
- Provide a helper-extensions to work with TargetPlatform
(in particular, for getting a specific component platform)
- Remove MultiTargetPlatform in favour of TargetPlatform
- Notably, this commit leaves another widely used duplicated abstraction,
namely, IdePlatform. For the sake sanity, removal of IdePlatform is
extracted in the separate commit.
Original commit: d5fbe59a3e
Change the copyright from "JetBrains s.r.o." to
"JetBrains s.r.o. and Kotlin Project contributors"
Update only 2 lines copyright.
Original commit: 65244b4bea
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.
Original commit: ea4fc0fb6b
Andrey Uskov