There are two reasons for this. First, this class will be used in the
metadata reading library which should not have dependencies on lots of
compiler stuff JavaToKotlinClassMap depends on.
Second, it was easy to accidentally break the deserialization in old
compilers by adding another mapping to JavaToKotlinClassMap. This was
possible because ClassMapperLite is used to decide whether or not the
JVM signature is "trivial" and should be written to the metadata (at
JvmSerializerExtension.SignatureSerializer.requiresSignature). If the
signature is trivial but mentions a type added in JavaToKotlinClassMap
in the new compiler, the old compiler will not be able to load the
signature correctly. See the comment on ClassMapperLite for more
information
Note, that this change potentially has some other effects in corner cases
(like the changed test data that is rather sensible because `bar`
in the example is not effectively projected out and can be called
with nulls)
Probably, we need to consider rewriting all other isSomeType methods
in KotlinBuiltins, but now it seems to be a rather dangerous change
#KT-16424 Fixed
Otherwise if Char value is a result of some erased generic call,
coercing it to I (primitive int) causes CCE at run-time.
#KT-23104 Fixed Target versions 1.2.40
Add missing long literal suffix
Add binary integer literals
Introduce IntegerLiteral lexer rule, which is closer to the actual lexer
Issue #KT-22713 Fixed
"kotlin-reflect" is a shadow jar which breaks incremental compilation
to avoid non-incremental builds, project should add
* `compileOnly` dependency on ":kotlin-reflect-api"
* `runtimeOnly` dependency on ":kotlin-reflect"
* `runtime` dependency is not recommended because it leaks into compile
* classpath
through transitive dependencies
LightClassGenerationSupport:
Includes utilities related to generating light classes
Primary client of this service are KtLight* implementation classes
KotlinAsJavaSupport:
Provides APIs to transform kotlin code into Psi* entities
Primary client of this service is JavaElementFinder
ReplErrorLogger is not really a class that logs errors, ReplWriter exists for that purpose (I don't think ReplWriter has a good API as well, though). The only thing it does is that is passes exceptions got from the compiler to IDE. So, in my opinion, the old name is rather confusing and it doesn't describe what the class actually do.
Also rethrow exceptions explicitly.
This fixes an exception from duplicateJvmSignature reporter
Fixes "QuickFixTestGenerated$Override.testDontOfferToImplementMembersForExpectedClass" on teamcity
Otherwise it's difficult to use a newly added API annotated with
RequireKotlin with the latest, not yet released, version.
For example, suppose there's a new function added in kotlin-stdlib,
since Kotlin 1.3, which requires 1.3 (Kotlin < 1.3 is supposed to report
an error on usages):
@SinceKotlin("1.3")
@RequireKotlin("1.3", COMPILER_VERSION, message = ...)
fun foo() {}
Until Kotlin 1.3 is released, the latest available compiler in Maven has
the version 1.3-SNAPSHOT, which is _less_ than 1.3 according to Maven
rules which are used in getDeprecationByVersionRequirement. Therefore,
errors will be reported on usages of foo, and there's no Kotlin compiler
version which can be used to verify if the function works correctly,
which is inconvenient.
Since SNAPSHOT versions are effectively "pre-release" in a way, it's OK
for them to skip reporting these diagnostics
Alexander Udalov