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
useCorrectedNullabilityForTypeParameters = true only might lead
to something becomes a DNN when otherwise it wasn't.
It seems safe to use it here, since if compiler has generated DNN, then
it's OK to assume that it checked necessary conditions, and it's likely
that it had useCorrectedNullabilityForTypeParameters = true as well, there.
Anyway, it looks saner than having an exception here.
Also, we assume here that metadata leading to exception might only be generated
with ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated LF
(at least, we don't have contradicting evidences),
thus it's mostly a preparations in case we decide to enable
ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated in 1.9.
^KT-55357 Fixed
^KT-55388 Related
^KT-36770 Related
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
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.
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
The `getSourceForArgument` method should be in the interface,
but adding it is a breaking change for Java usages,
since the module is not built with -Xjvm-default (KT-54749).
Move the method to an extension. This doesn't change the behavior,
since it was only ever called on LazyAnnotationDescriptor.
Since KT-53308, we started to cache results of typeOf invocation
in reflection. The cache uses the origin 'KClassifier' as a key with
an optional list of 'KTypeProjection' in type argument position,
and computed result as a value.
Without classifier check, the caching produces incorrect execution in
a very specific classloaders usage which is leveraged
by IDEA source-tree:
* All Kotlin stdlib and reflect classes are always loaded by the same
classloader
* Other classes that depend on Kotlin are loaded by separate
classloaders
The reproducer:
* Attempt to use typeOf<kotlin.List<Foo>> from one classloader caches
the resulting KType
* Attempt to use typeOf<kotlin.List<Foo>> from another classloader
for the same 'Foo' that differs only in classloader reuses the
computed KType, meaning that KType type argument classifier
is simply incorrect and points to the 'Foo' from the first classloader
#KT-54611 Fixed
#KT-54629 Fixed
Merge-request: KT-MR-7470
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
'equals' from any made available for overriding in inline classes
'typed' equals made available for definition in inline classes
'typed' equals definition made compulsory if 'untyped' is overridden
'operator' keyword is allowed in 'typed' equals definition
^KT-24874: Fixed
This is related to 8308f5d7d3 (KT-44977).
It turns out that it's necessary to create `ArrayValue` with a
precomputed type not only in case of annotations stored directly in
Kotlin metadata (i.e. annotations on types and type parameters), but
also for arguments of repeated annotations. The reason is that repeated
annotations are stored in an array themselves, as an argument to another
(container) annotation. The annotation-reading code unwraps this array
to load repeated annotations as individual instances of
`AnnotationDescriptor`, but in contrast to loading normal annotations,
it doesn't set `source` to the reflection object, it uses `NO_SOURCE`
(see BinaryClassAnnotationAndConstantLoaderImpl.AbstractAnnotationArgumentVisitor.visitArray).
So when kotlin-reflect is later asked for the arguments of the
annotation, it needs to recreate the reflection object from
`AnnotationDescriptor` in `util.kt`. Doing so requires knowing the array
type, which is now present because we're creating a `TypedArrayValue`
(previously `DeserializedArrayValue`) in places where arrays are read as
annotation arguments.
Alternative solution would be to fix source passed to
`AnnotationDescriptorImpl` in the annotation-reading code, but that
seems a bit messy because the code is very abstract and is used in lots
of other places.
#KT-53279 Fixed
Pavel Mikhailovskii