They were accidentally fixed with `[FIR] Process all overridden members from intersection scopes`
commit, which itself introduced incorrect behavior, which was properly
fixed with ... commit. So KT-64081 started to appear again
Previously, there was a contract that each callable symbol in the chain
of `processDirectOverriddenWithBaseScope` will be unique. And if some
symbol is accessible from multiple scopes, then only last of them will
be returned as a component of `MemberWithScope`
But after the change from previous commit, we don't have this contract anymore.
Which means that we may meet the same symbol during processing hierarchy
of overridden functions (but with different base scopes)
So if some code utilizes `process...Overridden...WithBaseScope` functions
it should consider that the same symbol may be obtained several times
^KT-63738 Fixed
In case of HMPP structure with common JVM module (e.g. shared between
JVM and Android) one can reference the same field from java code,
so it should be shared between fir2ir sessions
^KT-63574 Fixed
We shouldn't transform annotations not from declaration side due to
a possible different context and to avoid unexpected transformation of
unrelated declarations
Example:
```kotlin
fun implicitType1() = TopLevelObject.expectedType()
object TopLevelObject {
private const val privateConstVal = "privateConstVal"
fun expectedType(): @Anno(privateConstVal) Int = 4
}
```
Here we will try to transform the annotation from `expectedType`
during `implicitType1` and as the result, we will see unresolved
reference on the declaration side. This commit fixes this issue.
This solution is based on the fact that the compiler anyway will
resolve the propagated annotation on the declaration side.
And it doesn't matter if it is resolved before or after the call site
declaration transformation, because as a global result, we will observe
that all declarations are resolved correctly in the right context.
Hence, this commit fixes the issue in the case of "full resolution"
which is true for the compiler, but it is not correct for Low Level
FIR where we resolve declarations on demand. It will be solved in
the next commits
^KT-63042
Added two new cases:
1. division where denominator is `val` property
with zero initializer;
2. division where denominator is `const val` property
with zero initializer.
Both such cases have different sets of diagnostics compared to K1.
#KT-59894 Fixed
The issue appeared when we analyzed some typealias.
1. The typealias itself could be valid, but it could point
to an invalid type.
2. The typealias could point, for example, to an unsigned
type that must be handled in a special way
#KT-59894
Ilya Chernikov