In many other places, e.g. org.jetbrains.kotlin.codegen.ClassBodyCodegen#generateDelegatesToDefaultImpl
we implicitly assume that whenever we use a default interface method
our target is 1.8
But here, we don't and it might lead to exception in org.jetbrains.kotlin.backend.common.bridges.BridgesKt#findConcreteSuperDeclaration
when actual target is 1.6 and we extend some AbstractMap implementation
with JDK8 (i.e., with @PlatformDependent getOrDefault)
In case we extending some Map specialization with non-trivial type arguments,
e.g. Map<String, String> from Kotlin point-of-view it has
"remove(String, String)" signature while in Java it's "remove(Object, Object)".
So, we generate an override "remove(String, String)" in first Kotlin class of the hierarchy,
which body delegates to "super.remove(Object, Object)"
Also, we generate a final override for "remove(Object, Object)" to allow
for Java inheritors choose only the version with String while overriding.
The main idea of the fix is to make mayBeUsedAsSuperImplementation
return true in case of PlatformDependent annotations.
Otherwise, we weren't able to choose the impl from the java.util.Map
as a delegate in our bridge.
Another part of the fix is overriding `isDeclaration`:
it was necessary because otherwise bridge-generation algorithm
was assuming that there's already an actual declaration
in the first sub-class (TestMap) in the test and we need to
delegate to the latter instead of the method from the interface
^KT-26069 Fixed
Make a separate subclass for DescriptorBasedFunctionHandle
to allow customize the behavior without complex abstract concepts
like `areDeclarationAndDefinitionSame`
- Give it more clear name mayBeUsedAsSuperImplementation
because defining if it can be used as super-implementation
this is what it used for
- The meaning is negated, so it's needed to negate its usages and impls
- Also, reuse it in findSuperImplementationForStubDelegation
Functor is an imperative representation of function's contract (contrary
to ContractDescription, which is a declarative one). ContractDescription
is convenient when we deal with sources of contracts declarations
(binaries, source), while Functors are convenient for analyzing code
with contracts.
It means that we have to convert ContractDescription into Functor when
we start working with contracts. This computation isn't trivial, and
Functor and ContractDescription are in 1-1 correspondence, so we would
like to cache Functor for each ContractDescription somewhere.
We used to do this in binding trace, in slice FUNCTOR.
Now, it turns out that this approach causes "Rewrite at slice"
exception, see KT-28847. We won't go into details of why that happens
here, you can see the issue comments for details (but be prepared for the
very long and nitty-gritty story)
This commit removes the problematic slice and introduces another
approach, where Functor is attached to the ContractDescription, computed
lazily and cached here.
^KT-28847 Fixed
There are a few isolation modes for Gradle workers. KAPT uses 2 of them.
IsolationMode.NONE is the default. It runs workers in Gradle daemon and
is more memory efficient.
IsolationMode.PROCESS forks workers into individual processes. This
keeps some resource leaking annotation processors from affecting the
rest of compilation.
Users can specify kapt.workers.isolation=process, if they need to use
some annotation processor that are known to be resource leaking.
- add code formatting
- remove 'reference' adjective, as Kotlin doesn't distinguish primitives from reference types
- add the requirement of inequality to null
- replace inaccurate note with a link to the reference (relates to KT-26604)
#KT-14866
Dmitry Petrov