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
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
To avoid case with NPE due to race-condition on publishing
non-fully initialized object in ctor via
`TypeRefinementSupport.Enabled(this)`
#KT-59852
Merge-request: KT-MR-10917
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
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.
A module created for expression evaluation contains `fragment.kt`,
the file that contains necessary code for the expression
to be successfully evaluated (including the expression itself).
However, the IrFileImpl created for the fragment doesn't refer
to the module, leaving its lateinit `module` property uninitialized.
So, simply put, a parent has a child, but that child
doesn't have the parent. And that may lead to various errors.
Compose has a psi2ir lowering that transforms Composable declarations,
and for that it deep-copies all the declarations
(see `androidx.compose.compiler.plugins.kotlin.lower.
ComposerParamTransformer#lower`).
During the copying, it eventually tries to access that uninitialized
`module` property (`org.jetbrains.kotlin.ir.util.
DeepCopyIrTreeWithSymbols.visitFile`),
which predictably ends up with an exception.
The exception propagates down the stack, interrupting further
Compose lowerings, but eventually it gets swallowed at
`com.android.tools.compose.ComposePluginIrGenerationExtension#generate`.
So, fragment compilation continues and brings forth more complicated
errors on later stages, in particular during the codegen,
like in the IDEA-320738, when some declarations don't have
their lateinit `parent`s initialized.
This one example in the issue strikes during expect declarations
lowering at `org.jetbrains.kotlin.backend.common.lower.
ExpectDeclarationRemover.tryCopyDefaultArguments`.
The problem arisen in the issue could be solved on the Compose side,
but there's no telling what else can get broken because of
this module-file inconsistency.
Fixes IDEA-320738
Merge-request: KT-MR-10914
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
The cached `PsiSubstitutor` might be invalidated, in this case we should recompute the value
Also make the `JavaClassifierTypeImpl` to be thread safe
^KT-59667 fixed
^ 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
Igor Chevdar