In K1 (see LazyImportScope), default start import with different
priority worked as follows:
- if something is found in HIGH, don't look at LOW
- otherwise, look at LOW
That, in particular, helped to avoid looking into JDK mirroring classes'
constructors like when resolving calls like String(...) because we
just don't look into j.l.String while already found kotlin.String
The change inside FirTowerResolveTask.kt is not made accidentally:
- At first, it's more or less obviously a bug fix because tower group
for hide-members candidate with implicit receiver should take into
account the tower level of the receiver itself.
- The change is attached to this commit because otherwise the test
at compiler/testData/diagnostics/testsWithStdLib/kt55503.kt starts
failing.
The bug was hidden because previously after finding a successful
`Sequence.forEach` candidate for the inner receiver
(at the default HIGH star import scope), resolver was continuing to
look into default LOW star import scope where it's frozen forever because
we had the better/closer candidate anyway.
But after this change with merging default star imports into the same
tower leve, resolver was continuing its job, enumerating implicit
receivers, finding List<Int> there and noticing that there's
a TopPrioritized hide-member candidates for them
(erroneously ignoring it has a worse/more far receiver).
^KT-51670 Fixed
- At first, get rid of a kind of interceptTowerGroup callback and use
explicit towerGroup construction instead
- Get rid of INVOKE_RECEIVER (not sure exactly why it was needed)
- Make comparison consistent with tower-levels priority of K2
(see the comments in the compareTo code)
^KT-37375 Fixed
^KT-58940 Open
The problem is actually caused by 60f09f6512
It happened because we've been caching package scope using FqName key,
so once one file contains aliased import it would work like other file
contains it, too.
So, the fix is adding excludedNames to the key, too.
^KT-59789 Fixed
Namely, once a file in a package `foo` has import `foo.bar as baz`,
auto imported `bar` from the package name becomes inivisible in the file
^KT-54854 Fixed
When reporting INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION, search
for a call to a declaration with the type parameter that got inferred
into an empty intersection inside the expression.
#KT-56377 Fixed
FIR expressions rendered by FirRenderer don't look very nice in error
messages anyway, and additionally, they can become arbitrarily large,
so we shouldn't use them in messages.
#KT-59449 Fixed
Ilya Chernikov