FirReferenceResolveHelper internally checks whether the referenced class
id matches the qualifed access or not. If they do not match, it reports
an error. When the companion object has the same name as the class,
resolving a qualified expression access to a member of the companion
object causes an error because of the mismatch e.g.,
```
package my.sample
class Test {
fun a() {
my.sample.<caret>Test.say()
}
companion object Test {
fun say() {}
}
}
```
This commit fixes the issue.
TODO: When the companion object has a name difference from class, it
does not report an error but the resolution result is wrong in FIR. See
KT-56167.
---
Commentary from rebaser: the issue mentioned in this code is
fixed in 71a368e06e, so the actual
fix is omitted, and only test data is preserved
They are disabling error for using JS/Legacy backend via System property
by passing it to the Kotlin Daemon. But daemon may already be started
and not contain such property.
Workaround for now is to use 'in-process' compilation for such cases.
Source mapping URL is not saved in JS module cache anymore,
because it was a wrong url pointed to the source map from the cache.
Instead, the URL is appended every time on writing the output JS code.
^KT-56469 Fixed
Avoid assumption there, that for accessors we have a containing property
in the context
This necessary as a part of getting rid context modifications in checkers
element !is FirMemberDeclaration means that
`isAccessorWithSameVisibility == false` because
`FirPropertyAccessor <: FirMemberDeclaration`
Also, remove a function became unused
Now KtFirScopeProvider do not contain caches, so it can be reused between the threads. The only thread-local thing it had, was a ScopeSession. Now it's not stored in the KtFirScopeProvider
Not fully initialized DeclarationDescriptor could leak to bindingTrace.
It is hard to detect the outcome of that kind of leakage due to
possibility to have not fully initialized instances if PCE happens in
the middle of publication and instance full initialization.
#KT-56364
#KT-56388
#KT-54085
#KT-55150
SimpleFunctionDescriptorImpl initialization consists of two phases:
ctor + initialize.
When SimpleFunctionDescriptorImpl is created wrapped descriptor
(e.g. ValueParameterDescriptorImpl) is leaked through bindingTrace
with not fully initialized `containingDeclaration` (that is
SimpleFunctionDescriptorImpl).
If PCE happens after this unsafe publication prior to `initialize` then
it will be case with NPE on fully initialized instance reading.
#KT-56364 Fixed
PropertyDescriptorImpl initialization consists of two phases:
ctor + setType.
When PropertyDescriptorImpl is created wrapped descriptor
(e.g. WithDestructuringDeclaration) is leaked through bindingTrace
with not fully initialized `containingDeclaration` (that is
PropertyDescriptorImpl).
If PCE happens after this unsafe publication prior to `setType` then it
will be case with NPE on fully initialized instance reading.
#KT-56388 Fixed
Because SerializationJvmIrIntrinsicSupport does not instantiate annotations yet,
this info could be lost. As a workaround, it is possible to call Companion.serializer()
functions instead of direct serializer instantiation, as they are plugin-generated
and correctly handle annotations.
Note that for some cases (enums & interfaces) this WA is not enough, so additional work
is needed later.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2179
Jaebaek Seo