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 inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Compiler was running LTO pipeline without preliminary running normal
optimisation pipeline. In some cases this lead to unacceptably long
compilation.
Also, this allows disabling LTO pipeline part, having still quite
good performance, but much better compilation time.
Co-authored-by: Johan Bay <jobay@google.com>
^KT-55868
Use expanded ConeTypes to get correct parameters and return types
Also, fix the order of rendering modifiers in `KtFunctionalTypeRenderer`
^KTIJ-24527 Fixed
Previously, it was necessary because otherwise reporting diagnostics
from a checker of FirFile level didn't work
Now, it has been fixed in the previous commit
Previously, it was working for all the checkers but the file-level
DeclarationChecker's because when execution comes to
DeclarationCheck::check for a file, `containingDeclarations` is empty
(it doesn't contain the file itself yet), thus some things that rely on
CheckerContext::containingFile don't work properly.
For example, SimpleDiagnosticsCollectorWithSuppress.report that
effectively doesn't collect diagnostics when the containingFile is null.
This dependency has non-relocated 'com.intellij' types which could
lead to build errors if build classpath will have it earlier in the list
then kotlin-compiler-embeddable.
^KT-56414 Fixed
1. Introduce CExportFiles class
This class aggregates all files that are created specifically for
C export. Adding more such classes for other output kinds should
help getting rid of OutputFiles class.
2. Remove NativeGenerationState.tempFiles
Making NativeGenerationState (and compiler phases in general)
unaware of files and their lifetime is necessary for making phases
simpler and easier to compose.
We want to extract tempFiles from NativeGenerationState.
To do so, we need to move creation of NativeGenerationState from
`splitIntoFragments` function and untie CacheLlvmModuleSpecification
from NativeGenerationState
Vladimir Sukharev