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
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
Apparently it depended on the ordering of the synthetic `$annotations`
methods generated for properties. And those methods were always
generated at the end of a Java stub by kapt because they lacked PSI
element, and thus `ClassFileToSourceStubConverter.convertClass` could
not compute their source position, and it placed them at the end as all
other synthetic methods.
The solution is to provide PSI element for `$annotations` methods in
JvmDeclarationOrigin. This origin is then collected in kapt in
`OriginCollectingClassBuilderFactory` and used for sorting, as in the
case of the old JVM backend.
#KT-56360 Fixed
make write protection directly in properties
it creates no additional wrapper with the link to the containing class
for ij project, this reduces memory usage for ~15 mb
^KT-56351
We can use less strict rule for produced annotations:
* Previously: the same annotations from `findAnnotation` and `annotations`
have the same identity
* Now: the same annotations from `findAnnotation` and `annotations`
are equals by 'equals'
^KT-56046
Egor Kulikov