- do not allow it to be used together with JvmMultifileClass (otherwise
implementation becomes complex)
- do not allow to declare classes in a JvmPackageName-annotated file
(similarly, the implementation of this would be much harder in the
compiler, and there would need to be special support in the IDE)
- check that the value is a valid FQ name
- do not allow root package just in case
Otherwise, when completing all the unsuccessfull candiates,
resolution of each lambda-arguments starts repeatedly for each candidate
that leads to exponential time
NB: Changes in `completeArguments` are necessary because otherwise
nested lambdas will be analyzed twice:
once for the main resolved call, and then for all candidates
that again leads to exponential complexity
#KT-16672 Fixed
#KT-19457 Fixed
Previously there were three LanguageFeature instances -- Coroutines,
DoNotWarnOnCoroutines and ErrorOnCoroutines -- which were handled very
awkwardly in the compiler and in the IDE to basically support a language
feature with a more complex state: not just enabled/disabled, but also
enabled with warning and enabled with error. Introduce a new enum
LanguageFeature.State for this and allow LanguageVersionSettings to get
the state of any language feature with 'getFeatureSupport'.
One noticeable drawback of this approach is that looking at the API, one
may assume that any language feature can be in one of the four states
(enabled, warning, error, disabled). This is not true however; there's
only one language feature at the moment (coroutines) for which these
intermediate states (warning, error) are handled in any way. This may be
refactored further by abstracting the logic that checks the language
feature availability so that it would work exactly the same for any
feature.
Another issue is that the difference among ENABLED_WITH_ERROR and
DISABLED is not clear. They are left as separate states because at the
moment, different diagnostics are reported in these two cases and
quick-fixes in IDE rely on that
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
Use proper initial/frontend version of suspend descriptor
when writing METHOD_FOR_FUNCTION, because serializer uses this version
Also this commit contains adjustments of neighboring code to the describe
change
#KT-16093 Fixed
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
Nikolay Krasko