This is necessary for inference to work like in K1 because we only
add equality constraints from expected types on top-level `when`, not
on nested ones.
#KT-65882
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
Those only implement base classes, their members are not supposed
to be referenced directly (those sometimes they are).
So unused code in there can be suspicious.
On the other hand, some generated builders are truly unused, so leave
the suppression for them.
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
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
When collecting local properties for property initialization analysis,
the nodes of the CFG were navigated. However, there are problems when
trying to determine what local properties are defined within do-while
loops. This is because the node order of a CFG does not always follow
the FIR structure order.
By converting the collector to a FIR visitor, we can maintain the
structural order needed for finding properties defined within do-while
loops. This does require some additional logic though to make sure we
do not navigate into elements which are not part of the original graph
navigation.
^KT-65911 Fixed
Kirill Rakhman