Pass the metadata serializer instance instead. This allows to further
reduce code duplication by introducing the common interface
`KlibSingleFileMetadataSerializer` for abstracting away K1 and K2
representation of a source file, as well as reusing
`Fir2KlibMetadataSerializer` across different backends.
KT-64392
This reverts commit bb6f466162.
Reverting the fix for KT-57417 as it causes failures in IntelliJ and
Space projects. May reintroduce fix after failures are investigated and
resolved.
When a property is implemented via class delegation, it should be
considered unstable for smart-casting. This is because it is unknown
what kind of stability the underlying class delegate property has. It
could be a stable property, or it could be implemented via a custom
getter and unstable.
^KT-57417 Fixed
In some tests PSI and LT differ. Test data was fixed accordingly.
In the following tests I consider that difference is acceptable:
- compiler/tests-spec/testData/diagnostics/linked/expressions/try-expression/p-1/neg/3.1.kt
- compiler/tests-spec/testData/diagnostics/linked/expressions/try-expression/p-1/neg/4.1.kt
This is because:
- It only happens when recovering from syntax errors happened above in
code. I was unable to reproduce it in valid code.
- It doesn't break parsing further, the rest of the errors in file are
reported identically.
The rest of the tests will be fixed in subsequent commits.
^KT-62704 Fixed
This commit extends `LLFirLockProvider` API functionality to provide
`withJumpingLock`, which can be safely used in multithreaded scenarios.
Comparing to regular `withWriteLock`/`withReadLock`, the new API has a
bit more overhead as we have to maintain `jumpingResolutionStatesStack`
and `FirInProcessOfResolvingToJumpingPhaseState` even without contention.
See KDoc of `LLFirLockProvider#withJumpingLockImpl` for implementation
details.
The implicit type phase has been migrated to the new approach, so
now it is safe to drop the last global phase lock.
Potentially, we can have some benefits from migration of other
jumping phases to this API.
^KT-56551 Fixed
^KT-55750 Fixed
A report of UNRESOLVED_REFERENCE should not be made for elements like
FirImplicitThisReference that don't have a source, as they are implicit.
#KT-65044 Fixed
In convertDestructingDeclaration, property delegates are mistakenly
treated as valid expressions for destructuring, but they should be
ignored.
#KT-65021 Fixed
Substitution of type arguments to non-reified type parameters may lead
to accidental reification, which should not be done (see ^KT-60174 for
examples). So, we should erase them, except the few cases.
^KT-60174: Fixed
^KT-60175: Fixed
Motivation of using dispatch receiver type when calculating method owner
was discussed here: https://github.com/JetBrains/kotlin/pull/3054
However, this is incompatible with type erasure of non-reified type
parameters on inlining (which will be done in future). Consider the
code:
```
inline fun <T> f(arr: Array<T>, p: (T) -> Int): Int = p(arr[0])
fun box() = f(arrayOf("abacaba"), String::length)
```
After inlining and erasure, the type of `arr[0]` is `Any`. Thus, when
calculating owner of `String::length` we would have `Any` instead of
`String` if we used dispatch receiver type.
Note, that this change affects bytecode instruction that invokes
method, but does not change which method is being invoked.
- For synthetic calls
- For delegated constructor calls
Also, I checked that for each toResolvedReference() (beside annotations)
that converts candidate to the resolved reference,
we run `runPCLARelatedTasksForCandidate()` in the same context.
^KT-65103 Fixed
It's been used only for regular function call nodes resolution,
so I made it more explicit.
The main idea behind this change is ResolutionMode hierarchy
simplification and the kind of statement
that "AugmentedAssignmentCallOption" is only relevant to calls.
Instead, CallResolutionMode is introduced that is only used for
`transformFunctionCallInternal` call sites.
- Move it out of the ContextDependent hierarchy
- Get rid of many controversial checks that were necessary because
Delegate was a ContextDependent inheritor
- Actually fix semantics for lambda processing
Previously, lambdas as delegate expression were not being analyzed
thus leading to an exception (see KT-64635), and this change
forces analyzing them in the same mode as ContextIndependent
(thus `{}` made by default `() -> Unit` leaving to DELEGATE_SPECIAL_FUNCTION_MISSING)
Before this change, new test was failing with an exception.
I've analyzed all `is ContextDependent` and it seems that none of them
is relevant to delegates.
^KT-64635 Fixed
Build failure was introduced by `9b786d35`,
where I forgot that typealiases exist.
^KT-64891
^KT-65336 Fixed
Merge-request: KT-MR-14087
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
This is needed to gain access to providers functionality in those
utilities, which is important for support of FirDeserializedEnumAccessExpression
node (see later commits)
^KT-64975
Previously, when an Objective-C library had an unused Objective-C
forward declaration (`@class` or `@protocol`), cinterop tool didn't
include it into the resulting klib at all.
This led to a subtle bug (KT-64105). One Obj-C library has unused
Obj-C forward declaration, and another one depends on the first and
uses this forward declaration, e.g. as a function result type.
When building the first cinterop klib, this forward declaration is not
added to `includedForwardDeclarations` in the klib manifest (the
compiler uses this property to decide whether to synthesize the
corresponding class).
When building the second cinterop klib, the forward declaration is not
added to its manifest either, because it is located in the dependency
(and therefore should've been included there).
As a result, the forward declaration is included nowhere, and any
attempt to use it in Kotlin fails, including calling the function from
the second lib.
This commit fixes this bug by including even unused Objective-C forward
declarations, which is consistent with any other kind of declarations
and seems more natural.
^KT-64105 Fixed
K2 version runs like for 15s.
It became slow after PCLA (KT-59791) was implemented,
and the reasons for that is the presence of a lot of interconnected TV
which leads to O(NUMBER_OF_CONSTRAINTS*NUMBER_OF_VARIABLES)
asymptotic during constraint incorporation.
The test itself in any way doesn't represent some common BI use case,
so it seems reasonable to mute it temporary.
^KT-65005 Related
Yan Zhulanow