`kotlin.js.Console` is used instead of `kotlin.js.JSON` to avoid problems on case-sensitive filesystems since right now we also have `kotlin.js.Json` (will be removed later)
These two functions are supposed to fix an inconvenience in the design of
KProperty{1,2}.getDelegate for extension properties, where you have to pass an
instance of the extension receiver which is going to be completely ignored
#KT-8384 Fixed
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
The point here is to disable the "checkNotNewerThanCompiler" check because it
breaks a real life use case of compiling with an old compiler against the new
runtime library (that may come implicitly as a transitive dependency of another
library). However, to keep the possibility of restoring this check in the
future without backporting the needed changes into the old branches, we now
only perform this check for the "Core" runtime components, and all other checks
-- for "Core" and "Main" runtime components. In the follow-up commit, we change
the runtime component of our libraries to "Main". If we decide we need the
"checkNotNewerThanCompiler" behavior in the future, we can change the runtime
component to "Core", effectively restoring this check in the old compilers
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.
Inferred type of receiver of orElse is Optional<T & Any>
Generic descriptor is orElse(E!): E!
Substituted descriptor is orElse(T): T , and that is the problem.
Seems that E! => (T & Any)! gets expanded to just T or T & Any , however it should be expanded to
(T & Any) .. (T & Any)? => T & Any .. T & Any
T & Any is NotNullTypeParameter(T)
The problem is that (T & Any)? is expanded to T & Any,
that is seems to be wrong.
#KT-15236 Fixed
- calls must be prohibited iff they refer to some additonal built in member
- override must be prohibited iff all of the overridden descriptors are additional
Other usages were able to be successfully compiled by 1.0.x
Solution with @Deprecated(level=Error) doesn't work properly, because
deprecation propagates to overridden, thus call 'java.util.ArrayList<String>().stream()'
becomes invalid, while it was correct in 1.0.x
#KT-15794 Fixed
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.
Zalim Bashorov