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.
Before this change, deserialized scopes were not tracking lookups properly,
because lookup tracker was not passed from compiler configuration correctly.
Because of that, lookups from dependencies were not tracked,
so multi-module IC was not working (chages were passed between modules,
but affected source files were not invalidated).
Svyatoslav Scherbina