Namely, in the previous commit we merged two
(LOW and HIGH priority default start import scopes) into the single one
For more explanations, please look at the previous commit
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
To correctly provide the context for class header resolution, we save
the additional copy of the context right before `withRegularClass`
wrapper call in `LLFirBodyLazyResolver`. Otherwise we would have to
clear the existing context by hand, which is too cumbersome
(if at all possible)
^KTIJ-26024 Fixed
^KTIJ-24832 Fixed
Accessibility-related diagnostics for inline function have the inline
function symbol as a first argument, and the forbidden callee as a
second one.
^KT-59673: Fixed
The reason is that it's potentially might lead to some errors
are actually ignored leading to false-negatively green code,
while on the other hand we don't have any evidences (like tests)
that not-having the parameter lead to at least some redundant diagnostics.
^ KT-59705
If property is delegated, it can't have property accessors with non-default impl,
but it can contain property accessors declarations
with non-default visibility, annotations, etc.
Seems, it's more logical to preserve them as fake sources
than use property itself
- 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