To get rid of pointless/confusing implementations in ModuleDescriptor,
PackageViewDescriptor, TypeParameterDescriptor and others.
Note that there are still implementations that do not make sense, for
example in those subclasses of VariableDescriptor which are not also
subclasses of CallableMemberDescriptor (e.g. ValueParameterDescriptor).
Those can be removed by making CallableMemberDescriptor (instead of
CallableDescriptor) inherit from Substitutable. However, that would
require more changes in the compiler because CallableDescriptor is used
rather often in places where in fact only CallableMemberDescriptor
instances can appear.
Explicit return types and casts are required in some places now because
there's no single non-trivial supertype for
ClassifierDescriptorWithTypeParameters and CallableDescriptor.
Previously it was DeclarationDescriptorWithVisibility, now it's both
that and Substitutable<...>
Anonymous classes for local function references implement their
getOwner() as "return null" currently (KT-14291). To avoid NPE in this
case, we now consider two local functions the same if their name and
signature are equal. This is incorrect in general, but unlikely to cause
major problems and is going to be fixed by KT-14291 eventually anyway
#KT-17055
The <Type>Array.iterator used to lack next<Type>() method (KT-16626).
The -Xtypedarray compiler key enables translation of primitive arrays
to TypedArrays, and primitive array`is`-checks (KT-15358, KT-14007,
KT-14614, KT-16056).
This fixes KT-17001 because now 'header' modifier is loaded correctly
for deserialized members and the standard disambiguation in
OverloadingConflictResolver.compareCallsByUsedArguments takes place,
where header members are discriminated against the corresponding impl
members
#KT-17001 Fixed
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
allows to compile only parts of the source files, denoted by top-level
"sections" (function with lambda param calls), but preserving original
file line/column numbers for easier diagnostics. Allow e.g. to compile
gradle "buildscript" section without preprocessing original file in
advance. See tests for examples.
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
Consider this code:
object Delegate {
operator fun getValue(t: Any?, p: KProperty<*>): String {
return ""
}
}
class A {
val String.ext by Delegate
}
then the type of <p> is KProperty2 (it has 2 receivers).
Test fix + review fixes
The problem was that when resolving super-calls we used known substitutor
when creating a type alias constructor, thus its original return itself,
while it's expected that it should return the descriptor before substitution
The main idea of the fix that `createIfAvailable` should always return
unsubstituted constructor.
Note that known substitutor for type alias constructor should be based
on abbreviation.
The test change seems to be correct as PROJECTION_IN_IMMEDIATE_ARGUMENT_TO_SUPERTYPE
is already reported.
Beside this, resolution behavior isn't expected to be changed dramatically
See how we translate raw types to Kotlin model:
RawType(A) = A<ErasedUpperBound(T1), ...>
ErasedUpperBound(T : G<t>) = G<*> // UpperBound(T) is a type G<t> with arguments
ErasedUpperBound(T : A) = A // UpperBound(T) is a type A without arguments
ErasedUpperBound(T : F) = UpperBound(F) // UB(T) is another type parameter F
Stack overflow happens with the following classes:
class A<X extends B> // NB: raw type B in upper bound
class B<Y extends A> // NB: raw type A in upper bound
when calculating raw type for A, we start calculate ErasedUpperBound(Y),
thus starting calculating raw type for B => ErasedUpperBound(X) => RawType(A),
so we have SOE here.
The problem is that we calculating the arguments for these raw types eagerly,
while from the definition of ErasedUpperBound(Y) we only need a type constructor
of raw type B (and the number of parameters), we don't use its arguments.
The solution is to make arguments calculating for raw types lazy
#KT-16528 Fixed
Vyacheslav Gerasimov