See IDEA/f53c2114c38f856bdf0ff4d01de9fffeeeb630f2 commit.
In 222+ IDEA usage of the old ErrorUtils (and other classes)
was eliminated, but not in the 211-221 versions.
Relevant Kotlin commit: b5933c70e2
Also, I noticed that stub for createUnresolvedType do not
store arguments into Error type, so I've fixed that too
See IDEA/f53c2114c38f856bdf0ff4d01de9fffeeeb630f2 commit.
In 222+ IDEA usage of the old ErrorUtils (and other classes)
was eliminated, but not in the 211-221 versions.
Relevant Kotlin commit: b5933c70e2
Also, there is usages of UnresolvedType or ErrorType from
the org.jetbrains.kotlin.types package in the safeargs tests,
but it is difficult to restore the compatibility for them.
So, I decided that it is ok to eliminate them in the
`kt-[212|213|221]-*` branches, because it is tests and not
production
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
KotlinCommonMetadata can be used to inspect .kotlin_builtins and
.kotlin_metadata files. It's in an internal package for now, but might
be published once the API is finalized.
Fixes KT-50992
DeclarationDescriptor.isInlineClass misidentifies inline classes without
constructors. This can happen for the ABI of inline classes with private
constructors.
Implicit receiver type inside expect class is inconsistent with the
type resolved from an explicit reference inside that class. The former
one is a default class type, i.e. expect; the latter one resolves to
an actual type when either expect and actual are in the same module, or
when the sources are compiled for a particular platform.
The workaround is to manually actualize implicit receiver type for one
particular check affected by the broken subtyping.
KT-49714
This is much more correct, because we have one to one mapping for
special java functions in this case, so using single nullable name
instead of list of names makes code more readable
Please read the description of IDEAPluginsCompatibilityAPI.
Also, you may notice, that Deprecation annotation was removed.
That is because with level ERROR it isn't possible to opt-in
to such API in the legit cases. And with level WARNING it won't be
reported because We have diagnostic with level ERROR about OptIn marker.
Sadly, there is no way to add ReplaceWith to the OptIn marker
Mostly, it only affects FIR
It partially allows to consider several variance of constraints like
A<Int> & A<T> <: A<X_var> that are mostly brought by smart casts
^KT-49542 Fixed
^KT-50489 Relates
Denis.Zharkov