During this phase, the compiler will evaluate initializers of
const properties and defaults of annotation's constructor.
Evaluation results will be stored in corresponding attributes.
#KT-64151
In Native and JS, there is a special logic where the compiler saves
a copy of inlined function (see `InlineFunctionsSupport`). This copy
is used in the IR inliner. Because of that, we can't really compare
inlined function with other functions directly. We need to
get `originalFunction` first and save it.
`originalCallee` is supposed to be the owner of the original call.
It can be a fake override, and in the inliner we are using actual
function with body. Apparently we can just stick with the resolved
function.
#KT-64807
We are using `ConeKotlinType` instead of `FirTypeRef` to represent
that element type of vararg doesn't have any source. It has a type
that was inferred. If we try to specify a source, then we could
end up with the incorrect place for diagnostic.
#KT-59682 Fixed
This is an addition to the f5bb477459
commit. Earlier, some of the validation checks were moved from
`stickyPostconditions` into separate lowering. But these
post-conditions checks were launched only when several flags were
set to true. In this commit, we just return to such behavior.
#KT-64116
When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
This problem is extensively described in
`cadbc87dfd1ce3e63481ab90874ca8858878c55f` commit message.
TLDR: compiler is also called from Android LiveEdit plugin where
we want to be able to use compiler plugins. For that reason, we have two
different flags in the compiler. One is only for "evaluate expression"
(`doNotLoadDependencyModuleHeaders`) and the other for both LiveEdit
plugin and "evaluate expression" (`shouldStubAndNotLinkUnboundSymbols)`.
We want to forbid using compiler extensions for "evaluate expression"
and allow for LiveEdit plugin.
#KT-63695
Added two new cases:
1. division where denominator is `val` property
with zero initializer;
2. division where denominator is `const val` property
with zero initializer.
Both such cases have different sets of diagnostics compared to K1.
#KT-59894 Fixed
The issue appeared when we analyzed some typealias.
1. The typealias itself could be valid, but it could point
to an invalid type.
2. The typealias could point, for example, to an unsigned
type that must be handled in a special way
#KT-59894
This is an extended version of the fix in
57d912a5d4. We don't want to use any
plugins in code fragment compilation, but we still get them through
`project` because they are registered in IDEA. So we just fully
exclude `irPluginContext`.
#KT-63695 Fixed
We can omit `get` call to delegated property and inline
constant value directly. If we are not going to
do that, we can get a runtime exception because
all usages of const property will be inlined and the property
itself will be dropped.
#KT-63567 Fixed
#KT-63580 Fixed
`Generate Compiler Tests` configuration is not working properly
because it doesn't include analysis api test generator. It was decided
to keep only one generate configuration for tests.
This is the case when we have Java class in hierarchy. In this case,
we want to generate reflective access to the original Java method.
#KT-63642 Fixed
When compiling code fragment, we forbid to use `irLinker` as
IR provider. Because of that, if there are some plugin
extensions, we will not be able to find deserializer
for a given module and will fail.
#KT-63695 Fixed
Some boolean expressions could be transformed into `IrWhen`
node. To understand that this node is actually
a boolean expression, we need to analyze its origin.
#KT-62683
Try to use `IrModuleFragment` instead of `ModuleDescriptor`. This change
is required for the evaluate expression in IDE. When we compile
some code fragment with inline function call that has an anonymous
object in callee, we will get incorrect behavior. Code fragment is
wrapped in `EvaluatorModuleDescriptor` and we accidentally
think that inline call and callee are in different modules that
leads to an error in `AnonymousObjectTransformer.doTransform`.
#KT-63454 Fixed
We could get several files from the IDE to analyze. For example, some
code fragment and a file with context information. This additional
file, in fact, can be a file where a code fragment is defined, and we
can accidentally analyze a single file twice that leads to errors.
This change is required to support a new approach to lowering
execution. There will be no more guarantee that every module
will execute `JsDefaultArgumentStubGenerator` lowering before
moving on.
#KT-63073
`stickyPostconditions` are such conditions that are checked
every time after applying when a new lowering finishes its execution.
Right now we are using them only in JVM, and this is a blocker
for adopting Native approach for lowering execution.
In Native we are using
`SimpleNamedCompilerPhase<in Context : LoggingContext, Input, Output>`
as the common super type for all lowerings. Here we have `Input` and
`Output` that can potentially be different and `stickyPostconditions`
don't have much sense in that case.
In IR interpreter we have "preprocessors". Preprocessor is a
transformer that changes IR expressions in a way that we can
interpret them at least partially.
We have two places where interpretation is happening:
1. Right after fir2ir where we evaluate only strictly necessary
expression for `const val` and annotations.
2. In lowering for every backend where we are doing some
constant folding.
Earlier, to avoid double work, we didn't launch preprocessors
in backend if we were using K2. But this approach breaks compilation
for MPP projects where one module is compiled with K1 into klib
and the overall project is compiled with K2. On the backend side,
we are mistakenly assuming that preprocessors were launched, but they
were not.
The solution is to run preprocessors only on the backend side. If we
think about it, interpretation on fir2ir doesn't require any
preprocessing because we are working only with expressions that are
correct and must be fully evaluated.
#KT-62126 Fixed
Access to `SLRUCache` is a bottleneck when we call `getLineNumber`.
We are very rarely going to access the same offset. This change
speeds up backend by approximately 0.43%.
Ivan Kylchik