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
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
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.
Root cause: commonizer does not add `ExternalObjCClass` annotation
to expect declarations, so forward declarations aren't resolved.
It is simpler (and safer) to fix it on the compiler side by checking
superclass instead of annotation.
Support importing synthetic declarations from "magic" forward
declaration packages:
- cnames.structs
- objcnames.classes
- objcnames.protocols
So this is a rough equivalent to the forward declarations module
made of ForwardDeclarationsPackageFragmentDescriptor in K1.
Unlike K1 implementation, this K2 one doesn't allow importing
a declaration that wasn't actually forward-declared in a C/Objective-C
header available through a cinterop klib dependency.
This commit makes the compiler read the pre-release flag from loaded
klibs. Now the K1 frontend checks this flag in
MissingDependencyClassChecker checker, reporting errors if the current
compiler configuration doesn't allow using pre-release dependencies.
^KT-54905 Fixed
JsAllowValueClassesInExternals language feature had UNSTABLE_FEATURE
kind and was enabled by default for JS IR backend. As a result, klibs
compiled with recent compiler versions were marked with the pre-release
flag.
Now, if we enabled reading the flag from klibs, the JS IR compiler would
reject all these klibs by default. To fix that, this commit changes the
flag value from 0x1 to 0x2, so that all previously compiled klibs are
treated as not having the pre-release flag.
1539d7ef1a brought some package names in
sync with the directory layout. However, this broke some third-party
code that used classes from those packages.
The new compatibility aliases allow that code to continue to compile.
Deprecation warnings will be emitted, suggesting to replace the imported
packages with new ones.
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.
If we are compiling metadata, make synthetic forward declarations
`expect`, because otherwise `getFirstClassifierDiscriminateHeaders`
would prefer it over a "real" `expect` declaration from a commonized
interop library, which would ruin the whole idea of using synthetic
forward declarations only when no proper definitions are found.
^KT-51377 Fixed
Call mather relies on that BuiltIn package fragment implement specific
interface `BuiltInsPackageFragment` which was missed. Make sure that
BuiltIn module's package fragments implement that interface.
Fix progression optimizer symbols resolve in JS & WASM IR BE
`absoluteFile` is not enough to make path unique. For example, it doesn't
expand things like '..' and 'IDEAPR~1' on Windows. `canonicalFile` seems
to solve the problem.
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Pavel Kunyavskiy