Previously, we queried heavy kotlin package provider two times which affected performance
Now it's being queries only a single time
Also, the commit introduces separation for KotlinPackageProvider between kotlin and platform-specific packages
^KTIJ-24640
Annotation arguments that are resolved in COMPILER_REQUIRED_ANNOTATIONS
phase are resolved again in ANNOTATION_ARGUMENTS phase. If they resolve
to a different symbol, report an error.
KT-56177
There are cases when we have some indices in TypeRegistry left from
previous compilations, so registering new service may increase index
not by one
So such situation is possible:
First compilation (jvm project): register 20 different jvm services in
session + one from compiler plugin (with index 21)
Second compilation (common project): register only 10 common services in
session + one from compiler plugin (with index 21)
*numbers are imaginary
And in this situation increasing `ArrayMapImpl.data` size only one time
may not cover required index
^KT-56685 Fixed
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
TypeRegistry is the static map which contains mapping between type of
session component and its index in the session array. Originally
`KClass` of a component was used as a key in this map, which worked
pretty well for compiler components. But there was a problem with
components from plugins and Kotlin daemon: in compilation with daemon
we keep TypeRegistry between compilations. But for each compilation
we load plugins from jar, which brings to the situation when after N
compilations there is N entries in TypeRegistry map with different
KClass'es for same extension component. This not only causes AIOBE
but also introduces the memory leak, because we keep reference to
KClass which is not used anymore
So to fix this issue it's enough to just store FQN of component in
TypeRegistry instead of KClass
There are no tests in this commit, but they will be added in next
commit relevant to scripting. With those commits we will have gradle
integration tests which uses Kotlin compiler daemon and registers
a compiler plugin for scripting
^KT-55023 Fixed
Incompatible supertypes check also don't provoke runtime problems
in most situations, because this check is also bound to type argument
conflict. Related to KT-54411
The situations with conflicting type arguments normally don't provoke
any runtime problems. Also, conflicts like A<T> VS A<SomeType> aren't
valid at all. Here we decided to remove them to avoid strange
and non-actionable warnings in user code.
#KT-54411 Fixed
Quick quiz:
Q: In a CFG, what does `a -> b -> c -> d` mean?
A: `a`, then `b`, then `c`, then `d`.
Q: In a CFG, what does `a -> b -> d; a -> c -> d` mean?
A: `a`, then `b` or `c`, then `d`.
Q: So how do you encode "a, then (b, then c) or (c, then b), then d`?
A: You can't.
Problem is, you need to, because that's what `a; run2({ b }, { c }); d`
does when `run2` has a contract that it calls both its lambda arguments
in-place: `shuffle(listOf(block1, block2)).forEach { it() }` is a
perfectly valid implementation for it, as little sense as that makes.
So that's what union nodes solve. When a node implements
`UnionNodeMarker`, its inputs are interpreted as "all visited in some
order" instead of the normal "one of the inputs is visited".
Currently this is used for data flow. It *should* also be used for
control flow, but it isn't. But it should be. But that's not so easy.
BTW, `try` exit is NOT a union node; although lambdas in one branch can
be completed according to types' of lambdas in another, data does not
flow between the branches anyway (since we don't know how much of the
`try` executed before jumping into `catch`, and `catch`es are mutually
exclusive) so a `try` expression is more like `when` than a function
call with called-in-place-exactly-once arguments. The fact that
`exitTryExpression` used `processUnionOfArguments` in a weird way
should've hinted at that, but now we know for certain.
- `context(...)` is a modifier that must precede annotations and other
modifiers, so for declarations it is rendered in
`renderAnnotationsAndModifiers`.
- Ignore `@ContextFunctionTypeParams` in the annotation list of FE10
types, as the annotation is an implementation detail of context
receivers in K1 and shouldn't be rendered.
^KT-55098 fixed
Previously, FIR used `_context_receiver_n` while FE10 used `<this>` for
all context receiver parameters. This commit changes the code in FE10
to follow the convention from FIR.
Ilya Kirillov