Do not report an error on enum entry without initializer if all parameters have default values
(error is still reported if there is no such constructor, or if the constructor call is ambiguous).
Record resolved call on KtEnumEntry.
NB is the enum entry has a corresponding subclass, we still have to generate the "default" constructor call,
because FE doesn't know about the platform-specific representation of that class and its constructors.
See also KT-14097, KT-15900
#KT-10711 Fixed
#KT-12802 Fixed
#KT-12964 Fixed
#KT-15439 Fixed
Analyze callable references in `dependent` mode, then complete them with
respect to expected types
Property with type inferred from getter could access primary constructor parameters inside the getter
(which is incorrect, and caused problems in compilation).
Fix scopes for property descriptor resolution.
'getScopeForMemberDeclarationResolution' in AbstractLazyMemberScope should always return member declaration resolution scope.
Two scopes are required, because both property initializer and property accessors should see property type parameters.
See doNotCaptureSupertype test for clarification:
When resolving b.collect(toList()) we're building a common system with
two variables T and R.
The problem was that when introducing the constraint
C<T, Inv<T>> <: C<in String, R> we then were seeing the constraint
T <= in String, and add the constaint T=Captured(in String)
That lead to R=Inv<T>=Inv<Captured(in String)>, and after approximation
R=Inv<in String>, that is not the desirable result (Inv<String> suits here)
But the root problem was that we add captured constaint when projection was from supertype,
that seems to be wrong, and for example Java doesn't do that in the similar situation.
#KT-11259 Fixed
An overridden abstract member with a more specific "return type" than an overridden concrete member
should be explicitly overridden even if the class in question can have abstract members.
Update parser & descriptor renderer to handle parenthesized types and function types properly.
Resolve annotations in parenthesized types.
AnnotationsImpl.isEmpty() returned false for targeted annotations only
(e.g., 'fun @receiver:Ann C?.foo()').
Properly keep track of targeted annotations.
For special calls (when-expressions, if-expressions, etc.), do not attempt to
get type of the argument expression, which is the block with the callable
reference, instead get type of the callable reference itself. The difference
matters because for block expressions, a new lexical scope is created for each
getTypeInfo (see ExpressionTypingServices.getBlockReturnedType), and we do not
support rewrites of this value in the binding trace
#KT-12044 Fixed
Prepend the platform name to the diagnostic in a common module, which is
reported when sources of that common module are analyzed as a part of the
platform source set: "<!JVM:...!> ... <!>". Fix some existing tests, mostly by
adding "impl" to implementations
Denis Zharkov