The problem was that when obtaining char from the wrapper,
codegen used int as expected type that led
to a ClassCastException: java.lang.Character cannot be cast to java.lang.Number
The solution is using coercion to chars, it's still correct,
because of implicit widening coercion in JVM from C to I
#KT-15105 Fixed
LanguageVersionSettings can be read from the configuration. Also, the
configuration may be used for other stuff, not related to language version
settings, soon
Pass the LanguageVersionSettings instance inside the CompilerConfiguration,
since it's needed anyway. In compiler and tests, the configuration comes from
KotlinCoreEnvironment; in IDE, we're constructing it in JvmAnalyzerFacade
The problem was that in `Function<T>.apply(T)` T is now not-platform,
so when checking if not-null assertion is needed for parameter in SAM,
it's defined by the upper bounds of T that is a platform (Any..Any?),
and while it's definitely not marked as nullable it's still nullable
in a sense that it can contain null as a value.
So the solution is obvious
#KT-16413 Fixed
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
#KT-15783 fixed
When a daemon client cannot find an existing daemon, it starts a new one.
The client waits for a daemon to start and initialize.
Then the daemon is expected to signal that it is ready for compiling by printing message in stdout.
Before this change the message was the daemons' run path (a directory where all daemons store
their "flag" files).
However the path printed by the daemon was not matched by the path expected by the client somehow
on Windows for a user with a username containing non-English letters.
This commit replaces the message with the constant string.
The problem was that anonymous classes wasn't regenerated
although they capture another anonymous class that is a subject
for regeneration
#KT-8689 Fixed
This happened because of bae955aafd: similarly to the corresponding code in
the compiler, the IDE should also skip the metadata for kotlin.Cloneable when
decompiling built-ins because the deserializer is not going to resolve this
class from the metadata
Denis Zharkov