There are two visible effects of this change:
1) If an empty argument is passed in quotes, it will be parsed as an
empty string and handled by the compiler, which will report an error
later. The specific error is not very important because it's an edge
case anyway; at the moment, "source file or directory not found:" is
reported which is no better than the "invalid flag:" error reported
by javac in the similar case
2) It's no longer possible to split an argument into several parts and
quote them separately, such as:
"-langu"ag"e-"ver'sio'n 1.2
No test added for this change in behavior since it's an even edgier
case. Note that javac also prohibits this.
#KT-27226 Fixed
This is effectively a revert of
447c127036, which was an (incorrect) fix
for KT-22379.
The bug was that we've cleared data-flow info for assigned variables
*after* knowledge that loop condition if 'false' was applied (we can
claim that if loop has no jump-outs). Therefore, we broke smartcasts in
the innocent code like that:
var x: Int? = null
while (x == null) {
x = readPotentiallyNullableInt()
}
// x should be non-null here
Commit reverts that "fix" for 1.3.0 and postpones deprecation until 1.4
KT-22379 Open
KT-27084 Fixed
Note that previously we implicitly ignored JS_IR backend when directive
COMMON_COROUTINES_TEST was enabled, see kotlin/generators/util/coroutines.kt#L57
Both for callables obtained via reflection API (KClass.members etc) and
for callables obtained via ::-references, the instance parameter is now
the class which was used to construct the type at the left-hand side of
the reference, NOT the class where the callable is originally declared
as is known at compile-time. The reason is to reduce the difference in
behavior of KCallable.call vs FunctionN.invoke: the latter always
required the subclass instance for a fake override, and it's reasonable
that the former would require it as well.
Note that in Java reflection, behavior could differ in a similar case.
For a simple fake override, Class.getMethod would return the method
declared in the base class and that method will accept instances of the
base class in invoke. However, it's difficult to rely on this behavior
because if there's a bridge for a fake override in the derived class
(e.g. when overridden members have different signatures), the returned
Method object is accepting the derived class as the receiver. This just
confirms the fact that Java reflection operates on a different level of
abstraction, namely JVM methods in .class files, which is not applicable
to our use cases directly. Another reason not to replicate Java
reflection's behavior is the uncertainty as to which member is returned
in case there are several in the hierarchy for a given fake override:
see the "otherwise one of the methods is chosen arbitrarily" note in
javadoc on Class.getMethod.
#KT-24170 Fixed
It's difficult to fix KT-22818 until the IR comes along, so we're
providing a workaround where one can disable the
ACTUAL_FUNCTION_WITH_DEFAULT_ARGUMENTS error and provide default values
in the actual function, to avoid exception from the backend.
#KT-22818
We have an extra parameter in the mapped signature, and don't care about
Kotlin types there (so far). Might be a better idea to obtain the actual
descriptor for a suspend function (with extra parameter), and pass
arguments accordingly.
When we've determined that we are going to invoke an erased inline class
method ('static foo-impl(this, ...)' in inline class), keep track of it
so that the remaining type mapping logic proceeds correctly.
#KT-26998 Fixed Target versions 1.3.20
Dmitry Petrov