Backend, which is used by the expression evaluator, relies on the class
name in 'FacadeClassSource'. To pass the correct JVM class name,
stubs for top-level functions and properties got the 'origin'.
Also, adjust NativeIrLinkerIssuesIT after 5f3dad1. See the explanation
below.
5f3dad1 makes -Xlazy-ir-for-caches disabled by default. So the compiler
now deserializes different subsets of IR and in different orders.
As a result, the error message for a test changes. Both error messages
(before and after this commit) are correct, and the selection depends
on the IR deserialization strategy.
Moreover, this commit changes the expected error message to the initial
version, used before -Xlazy-ir-for-caches was introduced.
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
Calls to extension functions imported from objects have implicit
dispatch receivers, but those receivers are not present in the code
and should not be analyzed by the shortener
^KTIJ-26103 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
By default, tasks should opt-in for supporting build cache through
marking class with @CacheableTask.
However, some tasks should not be cacheable by default, as for these
tasks doesn't do any heavy load. Even worse, storing and extracting
tasks results from the remote cache (for example) would take more time
than actual run on host machine.
So these tasks are marked as @DisableCachingByDefault
^KT-59307 Verification Pending
aleksandrina-streltsova