There were several problems with it:
1) `isMoreSpecific` should return true if a == b. Otherwise
`isMoreSpecificThenAllOf` would never return true because it's always
invoked with a collection that contains the candidate. K1 behaves
similarly, `OverridingUtil.isMoreSpecific` returns true if a == b.
So in fact, "more" should be understood as "not less" here.
2) `transitivelyMostSpecificMember` in `selectMostSpecificMember` was
always equal to the first element, so `isMoreSpecific` was invoked
with incorrect arguments.
3) At the end of `selectMostSpecificMember`, we selected the first
candidate with the non-flexible return type, however only dynamic
type was considered. We need to check `isFlexible` via type system
instead.
#KT-66120 Fixed
`@Suppress` annotation has `VALUE_PARAMETER` target, so when a property
in the primary constructor is annotated with `@Suppress` it sticks
to the parameter. But the suppression should work for all diagnostics
reported on the parameter **and** the property
^KT-66258 Fixed
There were two lazy properties in `KtPsiSourceElement`, which were
rarely computed, which led to the fact that source element retained
a lot of memory for those lazy delegates
^KT-66172 Fixed
Most of them are passed at all call sites anyway. Having default values
makes it easy to forget to pass some meaningful argument (especially
`LanguageVersionSettingsImpl.DEFAULT` seems scary), and complicates
refactoring.
in effort to simplify implementation classes when possible.
Those two properties always point to IrFactoryImpl, so it may as well
be used directly.
#KT-65773 In Progress
It was the only IrElement with custom toString. And there is
a pending MR, which will override toString in IrElementBase, so this one
would be useless.
#KT-65773 In Progress
A Kotlin interface can have abstract members regardless of its modality. However, this invariant was previously ignored by FIR checkers. As a result, false-positive `ABSTRACT_<MEMBER>_IN_NON_ABSTRACT_CLASS` errors were being reported in explicitly non-abstract interfaces.
This commit makes a relevant FIR utility used by relevant FIR checkers aware of the aforementioned invariant.
#KT-66260 Fixed
Proof of concept that FirFunctionCallRefinementExtension (new) and
existing extension points can be used together to update the return type
of the specific calls and generate members based on call arguments.
Important implementation details:
- FirDeclarationGenerationExtension must be used to generate members of
generated local classes.
- FirExtensionSessionComponent together with firCachesFactory to pass
information between `intercept` and `transform`
Actual plugin is developed as a part of Kotlin dataframe repository
KT-65859
This extension point allows changing the return type of call
from a declared type to its subtype.
With an idea that such a plugin needs the ability to
control available (extension) properties for this type.
A set of properties should be decided based on the resolved function,
provided arguments, types, and resolved lambdas.
It is not a goal to enable plugins to affect resolution in any way.
Types are not intended to have any structured capabilities
In other words.
The goal was to come up with a way to enable a limited form
of an "extensible records" mechanism through plugins.
- It should give enough value for a practical use.
(more info in the ticket).
- It should have minimal effect on the compilation process
This appears to be an extension point that solves this problem.
^KT-65859 Fixed
This element has been introduced to simplify resolution logic in LL FIR,
but now this element is redundant and only complicates the code as after
KT-56683 `FirFile` has real phases
^KT-65876 Fixed
Get test arguments from the process arguments and environment.
There is the following order to get args:
1. Get from the process arguments.
2. If no arguments are specified, try to use process environment.
3. Get the KotlinNativeTestArgs key from the Info.plist.
Part of the ^KT-58928
Ilya Goncharov