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
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
^KT-59297 Fixed
'ProcessCancelledException's are commonly thrown during code analysis,
yet not every place is ready for them. As a FIR tree is a mutable data
structure with no transaction support, sporadic halts during its
mutation might easily leave it in an inconsistent state.
Before this change, whole module sessions (with all dependents) were
invalidated if an exception occurred during their analysis. Not only it
was very ineffective, it also resulted into a concurrency problem.
'ProcessCancelledException's are thrown when an underlying progress
indicator is invalidated. As analysis in each thread might have its own
progress indicator, invalidation in one thread should not stop
analysis in others. However, it is impossible in the current state,
as all threads share the same FIR tree structure.
The change introduces 'FIR guards' – a set of instructions defining
preservation and restoration rules for individual state items. As each
resolution phase is supposed to modify only a (sort of) known subset
of tree elements, restoration of potentially changed state on a failure
effectively returns the tree consistency.
Note that guards are not defined for certain phase transformers. The
reason is that the transformers already update the tree content safely.
E.g., the type reference is updated once it is resolved, and already
resolved type references are either resolved the same way again, or
just skipped on consequent phase runs.
aleksandrina-streltsova