FirFile after KT-56683 has its own phases and resolution logic,
so we should have a separate API for lazy resolution for FirFile and for
the entire file
^KT-61296 Fixed
In this commit we begin counting a catch parameter as
both a local variable and a value parameter for the purpose
of annotation targeting.
#KT-61691 Fixed
Normally such types are resolved during enhancement,
but creating the suspend view happens before
enhancement, so the type may have not been resolved.
^KT-59915 Fixed
This fixes a false positive OVERRIDING_FINAL_MEMBER caused by a
package-private member in a different package being added to the
list of overridden symbols. However, in Java, package-private members
from different packages are effectively like private members in that
they cannot be overridden.
#KT-61696 Fixed
For members of nested classes inside expect class
`classWrapper.hasExpect()` would be false, because it only reflects
modifiers of nested class itself and not aware of "expect" modifier
inherited from the parent class.
Fix is done in same way in PSI2FIR, see
`PsiRawFirBuilder.Visitor.toFirProperty`.
This fix now makes it possible to add test for functionality from
previous commit.
Review: KT-MR-12107
^KT-61784
...not reporting on companion object members as well as other
nested classes.
Annotation classes are accepted because this is how it already worked,
see other tests, for example `annotationsViaActualTypeAlias.kt`.
Test for nested annotation classes will be added in subsequent commit,
because it currently will fail in test
`TreeCompareTest.testCompareDiagnostics` because light-tree2fir
produces different tree due to a bug when converting properties
from expect primary constructor. See subsequent commit for a fix.
Review: KT-MR-12107
^KT-61784
See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
The original Java checker has an early return in
case of `resultingDescriptor !is JavaClassConstructorDescriptor`.
It fires if the descriptor is
`TypeAliasConstructorDescriptor`, thus further
diagnostics are not reported.
strangepleasures