Expression '1.unaryMinus()' is resolved as Int::unaryMinus call with Int receiver.
However, this expression is implicitly coerced to a different integral type (Byte, Short, Long)
based on results of constant evaluation.
Introduce IMPLICIT_INTEGER_COERCION type operator to handle such cases.
TODO: should we use it for simple constant expressions like '1' and '-1'?
To prevent tests from altering outcomes of the subsequent tests.
Also expose the clearCaches method (in the internal class
ReflectionFactoryImpl) so that it can be used in other places in similar
circumstances
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
Finnaly markers are used only for non-local return processing and are removed after inlining to non-inline functions, same deletion should be performed on inlining to anonymous objects
#KT-16532 Fixed
The problem was that he number of mask parameters for defaults when
generating methods declaration was being calculated upon resulting signature
(with additional parameters: extension receivers, enum name/ordinal),
while on call-sites the masks number was calculated by the arguments number
in resolved call, i.e. by the number of real value parameters.
And because of the additional synthetic parameters (like enum.ordinal) these
two numbers could be different.
The solution is just to use value parameters number in both places.
Note, that we only count value parameters from the original sourse
declaration, ignoring synthetic ones generated by backend (e.g.
Continuation for suspend functions)
#KT-14565 Fixed
See the issue and the test. The problem was that when generating
call to `foo` method in member scope of `AT<*>` its resulting descriptor
after substitution and approximation was: fun foo(x: Nothing..Array<out Nothing>).
This signature is correct, but when using this parameter type
for generating a vararg argument the assertion is violated that
the type of the argument must be an array
(by default we're using lower flexible bound everywhere)
The solution is using upper bound for flexible types that should
always have a form of Array<out T> for varargs (even for such corner cases)
both for Kotlin and Java declarations.
#KT-14607 Fixed
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
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.
Dmitry Petrov