Refactor the renderer, make BoundSymbolReferenceRenderer a static class
to prevent calling RenderIrElementVisitor's methods from it to avoid
infinite recursion in the future.
^KT-52677 Fixed
- Allow 'lateinit' for inline classes which underlying type
is suitable for 'lateinit'
- K2: report all problems related to 'lateinit' modifier
^KT-55052: Fixed
It's anyway safe to use avoidComprehensiveCheck = true because
during deserialization we're sure that we need DNN type because
it's been serialized as such.
This makes the `returns() implies` checker slightly cleaner, and also
fixes the case that I've missed where in RHS of `x ?:` type of `x` was
not set to `Nothing?`.
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
But not substitution overrides! This is important if the method called
is an intersection override where one of the intersected types is a
subtype of a generic type.
'findKotlinClassOrContent()' does not really distinguish between
outer class names and package path components, so it might return
'foo/bar/Baz.Boo' for 'foo/bar/Baz/Boo'. Possibly because
'findKotlinClassOrContent()' potentially returns a raw byte array,
ClassId checking is supposed to be performed in
'extractClassMetadata()'. For Java, it happens inside
'FirJavaFacade.findClass()', yet for Kotlin the check was absent.
Create the field directly and maintain the fact that its corresponding
property is the companion object property. That property has the
deprecated annotation which puts the deprecated marker on the field
when code generating the field.
^KT-54840 Fixed
Merging array types with different element types, for example
`[Lj/l/String;` and `[Lj/l/Object;`, now produces `[Lj/l/Object;`
(instead of `Lj/l/Object;`), which allows for more precise tracking of
null values because we assume that AALOAD on a non-array typed value is
possible only if that value is null.
#KT-54802 Fixed
In FIR we desugar when with multiple conditions leading to same block
as tree of OR expressions
Given
```
when(some) {
"a", "b", "c" -> {}
else -> {}
}
```
actually desugared into
```
when(val <subj> = some) {
<subj> == "a" || <subj> == "b" || <subj> == "c" -> {}
else -> {}
}
```
There is a multiple ways of how we can organize such expressions in FIR
Previously it was just nesting-chain of OR expressions
While the most efficient way in terms of required stack depth is
a balanced tree
KT-53255
Evgeniy.Zhelenskiy