If forward declaration exists in a library, it was
possible to import it both by forward declaration name
and normal library name. This is strange unique behavior.
And it would also make KT-59643 changes binary incompatible.
So from now it's only possible to import forward declaration by
forward declaration name only.
^KT-59642
This is refactoring in preparation for KT-59764.
Names and layout of forward declarations related classes
was copy-pasted many times over compiler code.
Implementing KT-59764 would require copy-pasting it two more times.
So instead of doing this it was put in single place.
No behaviour changes intended in this commit.
Flag, Flag constants, Flags typealias, flagsOf() function, and
Flag accessors in nodes (such as KmClass.flags, KmClass.jvmFlags, KmProperty.setterFlags, etc)
#KT-59440
Introduce extensions for KmNodes to work with various modifiers instead of old Flags.SOMETHING.invoke(flags).
Provide Visibility, Modality, and Kind enums.
Introduce KmPropertyAccessorAttributes to replace KmProperty.getterFlags and KmProperty.setterFlags.
Deprecate nodes constructors which take flags but not flags itself (yet).
Adapt KotlinP to changes.
#KT-59440 Fixed
Review: https://jetbrains.team/p/kt/reviews/8401
In scope of: KT-55082
Because this version isn't used for anything. We have KotlinAbiVersion
to version the IR format.
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
Review: https://jetbrains.team/p/kt/reviews/6753
This commit doesn't fix any issue except for "cleanup". If you find a
mistake in this commit feel free to revert part of it/the whole commit
I checked every module where I drop ':dist' dependency. Tests still pass
in those modules
^KT-52050 Verification Pending
The issue described in KT-52050 happened, because forwardDeclarations
were not carried into next commonization steps. For commonization
it is fair to choose the union of all modules forwardDeclarations
as common dependency (instead of a union), since we can assume that
all those forward declarations will be provided.
After commonization a type might additionally reference a abbreviated
type which is not present in the reference module's metadata.
This was even considered 'OK' before this commit, however only
under a special condition which might be too strict.
Right now, this newly introduced test will only enter the
newly allowed branch. This shall be re-reviewed later.
KT-51686
If the same NullableSingleInvocationCommonizer is reused for any reason,
it will store next inputs alongside previous, which is totally not
expected
^KT-51528 Fixed
Commonized type should match the platform's `platform.posix.ssize_t`
type alias' width. The implementation hard-codes platform widths for
all the targets, this can be potentially changed to search for ssize_t
in dependencies and get width from its type.
Use real targets in platform int commonization tests.
KT-41509
Add settings for a more fine-grained control over commonizer features
that will be added in the future
Add setting and KGP flag for optimistic number commonization
KT-51011
Initially it was restricted to work with type aliases only KT-48455
see test `test property with aliased number return type`
This limitation should be lifted now in order to fix KT-48568
^KT-48568 Verification Pending
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
Nikita Bobko