But when running code, do it via <java> task, not via custom testing code. Most
of the time the compiled code need not be runned, because it's irrelevant to
the Ant task itself
'kotlinCompiler' test is deleted because it's a very roundabout way to compile
Kotlin and Java sources, and there's no point in testing it.
'javacCompiler' test is deleted for similar reasons: using javac's "compiler"
option is not an advertised way to use Kotlin Ant task, and anyway it will work
with any CompilerAdapter instance, so it's hard to break it (apart from
deleting "withKotlin" adapter).
There are tests which check compilation/running of the same code but with the
recommended method. The pretext for deletion of these tests is to make Ant
tests generated, and that would be easier if they wouldn't depend on any outer
variables
This change requires withKotlin to be run with Ant of version at least 1.8.2.
Some test data changed because now compileList contains both Java and Kotlin
sources
#KT-7870 Fixed
Ant 1.8.2 has the API (namely,
CompilerAdapterExtension#getSupportedFileExtensions) which will allow to fix a
critical bug in <withKotlin/> task (see KT-7870)
For example,
KMemberFunction2<T, P1, P2, R> : KMemberFunction<T, R>
So for this inheritance the heuristic that was present ("take the last K type
parameters of the subclass, and substitute for K parameters of the superclass")
was wrong. The new heuristic for this case is: take type parameters with the
same names.
Also don't store "parameters" in a lazy value, since it's easy to compute and
it's computed practically every time anyway
@platformName is now supported for final non-overriding class member functions
(including property accessors).
Front-end provides diagnostics for inapplicable annotation cases.
Code generation updated:
- ignore kotlin.platform.platformName annotation for Java class methods;
- bridges generation generates proper JVM declarations in case of methods renamed with @platformName.
@platformName-related tests added.
#KT-5524 Fixed
It's needed to prevent NPE when requesting non-nullable visibility of descriptor
before `initialize` has been called.
Currently it happens because of indirect calls of `DescriptorUtils.isLocal`
between descriptor creation and it's initialization.
Non-member descriptors, e.g. type parameters, value parameters that defined in local function should be local too
Otherwise a lot of exceptions happens when resolving references within anonymous objects
Alexander Udalov