This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
- KTIJ-24574 occurred because a local destructuring declaration was
erroneously returned as the non-local containing declaration of an
element by `getNonLocalContainingOrThisDeclaration`. This occurred in
`init` blocks.
KTIJ-24574 fixed
Before we resolved all declarations to body resolve.
It was rarely needed and badly affects performance.
If the resolution will still be needed, it will be lazily performed by KtSymbol
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.
Kirill Rakhman