There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
In the stdlib implementation, render "!" if the type is only
nullability-flexible. Otherwise, render "($lower..$upper)".
Note that full kotlin-reflect has a much more complicated logic (see
`DescriptorRendererImpl.renderFlexibleType`) that renders things like
`(Mutable)List` and so on. It is not a goal of the stdlib implementation
to replicate all of that, since it requires copying a large amount of
code, namely the entirety of `JavaToKotlinClassMap` to map Java class
names to Kotlin.
The proper support will come in KT-15518, but that would be a breaking
change even for stable Kotlin without kotlin-reflect. Before that issue
is fixed, represent Nothing in types with the Void class, and use a flag
in the no-reflect implementation to remember that it's not actually the
Void class itself.
#KT-39166 Fixed
- Int.toChar was left non-deprecated because the replacement is not intrinsic yet.
- Number.toChar was left non-deprecated because otherwise the deprecation propagates to the override, Int.toChar.
KT-23451
Deprecate specialized unsigned iterators for removal.
Fix compiler tests:
- drop unsignedLiteralsOn1_2 because apiVersion 1.2 is no longer supported
- drop experimental unsigned literals diagnostic test
DefaultConstructorMarker is used as a marker to ensure that a
constructor is unique for companion objects. Prior to this change,
DefaultConstructorMarker was package private.
Being package private worked when calling the
DefaultConstructorMarker-marked constsructor using `invokespecial`,
likely because the JVM may not perform strict access checks in this
situation.
However, when access checks are performed, trying to call a
DefaultConstructorMarker-marked constructor will fail. This could happen
if the constructor was called using reflection or the MethodHandle API.
These APIs may be used by tools that perform bytecode instrumentation
on Kotlin JVM bytecode, such as Robolectric. It also caused problems
when using ByteBuddy validation.
Fixes https://youtrack.jetbrains.com/issue/KT-20869
This makes 'test.' an implicit package prefix, thus fixing the inspection
"Package directive doesn't match file location" positive in almost all
test files.
Alexander Udalov