Set constructor return type in FunctionDescriptorResolver#createConstructorDescriptor
(it seems to be the only place where ClassConstructorDescriptorImpl#initialize(...)
is called, but returnType is not set).
Provide proper dispatch receiver parameter for delegated members.
Use dispatch receiver parameter for delegated members in IR generation
for delegated member body (and check that the receiver has corresponding type).
When there is unsuccessful (e.g invisible) result of one kind (static/non-static)
and there is a successful candidate for another kind, choose the latter one.
Note, that we have to postpone commiting trace until we choose one of the results,
otherwise errors of unsuccessful results are reported
TODO: Maybe it makes sense to report all results when all of them are
unsuccessful (NONE_APPLICABLE or something like this)
#KT-16278 Fixed
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
The problem was that LanguageVersionSettingsImpl.DEFAULT did not have
"WarnOnCoroutines" as a feature and so it was manually added to the settings,
but only in two places: in the compiler and in the IDE
LanguageVersionSettings can be read from the configuration. Also, the
configuration may be used for other stuff, not related to language version
settings, soon
In most of the cases it was used together with CLASS_ONLY and vice versa
They only case when CLASS_ONLY was used without INNER_CLASS
is possibleParentTargetMap.COMPANION_KEYWORD.
But after diagnostic NESTED_OBJECT_NOT_ALLOWED has been introduced,
there's no sense in the restriction of exactly the companion's parent
For clarification see test data changed
Method `isBuiltIn` may not work correctly as built-ins are becoming
more and more like a usual dependency. Also behaviour of this method is
depend on the target platform.
General effect will be the following:
- all member scopes for libraries and JDK will be constructed with -language-version/-api-version specified in project settings
- for modules with another (not like in project settings) -api-version or -language-version we will have not correct member scope -- for example we will see typealiases from such libraries.
#KT-15979 Fixed
(cherry picked from commit 0001865)
This change fixes an SOE in isCastErased:
@JvmStatic
fun isCastErased(supertype: KotlinType, subtype: KotlinType, typeChecker: KotlinTypeChecker): Boolean {
if (supertype.isMarkedNullable || subtype.isMarkedNullable) {
return isCastErased(TypeUtils.makeNotNullable(supertype), TypeUtils.makeNotNullable(subtype), typeChecker)
}
TypeUtils.makeNotNullable(TypeTemplate) should not return the same object
if isMarkedNullable returned true on the instance
#KT-15516 Fixed
Dmitry Petrov