Denis.Zharkov
01354c8ce5
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
9 lines
229 B
Kotlin
Vendored
9 lines
229 B
Kotlin
Vendored
// FULL_JDK
|
|
|
|
val sRef = ::String
|
|
|
|
val s = String(byteArrayOf(1, 2, 3), 4, 5, <!ARGUMENT_TYPE_MISMATCH!>6<!>)
|
|
|
|
val s2 = java.lang.<!DEPRECATION!>String<!>(byteArrayOf(1, 2, 3), 4, 5, 6)
|
|
val s3 = String(byteArrayOf(1, 2, 3), 4, 5)
|