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
* Move source artifacts to KotlinVariant classes (since joint Android
variants may have multiple source artifacts, make it a set)
* Change lowerSpinalCaseName to dashSeparatedName (doesn't transform
the strings to lower case inside)
* Don't transform the project name to lower case (in the future, it may
be reasonable to stop transforming the target and component names, too)
Still transform the target names and the component names.
Currently, this is the way we don't break existing publications and may
still reconsider this in the future.
* Add a workaround for a list of GString's assigned to
publishLibraryVariants
* Check for Android library variants existence in a more strict way,
report existing variants that are not library variants.
A dependency on a multiplatform module with a jvmWithJava target failed
to resolve because the 'apiElements' and 'runtimeElements'
configurations didn't have the attribute 'localToProject' set to
'public'.
Those configurations need to have have the attribute set as per the
fix of KT-28795, but it doesn't happen.
Issue #KT-29035 Fixed
As KotlinCompilation only contains the directly added source sets in its
`kotlinSourceSets` property, we need to provide a convenient way to
collect the whole source sets hierarchy for a compilation.
We added internal `allKotlinSourceSets` some time ago, and it seems
reasonable to expose it as public API.
Issue #KT-28749 Fixed
As we introduced the 'api' configurations for Kotlin source sets, the
Java plugin did not link these configurations to its 'apiElements', and
those dependencies would only get published with the 'runtime' scope
through the 'implementation' configuration.
To fix this, manually specify that 'apiElements' extendsFrom 'api'.
Issue #KT-28355 Fixed
In Gradle 5.0, the 'prefer' function semantics has changed, and now a
transitive dependency version wins over the 'preferred' one. Instead,
'require' has been introduced in 5.0 with the old semantics.
Our users expect that the default Kotlin dependency version will be
at least as new as the plugin version, so we now need to use 'require'
with Gradle 5.0+
Issue KT-28820 Fixed
As non-Gradle consumers and Gradle consumers with metadata disabled
cannot read Gradle metadata, in POMs (the only source of dependencies
for the consumers mentioned above), we should publish the dependencies
on modules with metadata as the target artifact IDs rather than the root
MPP module ID (e.g. 'foo-jvm' rather than 'foo').
To do that, we rewrite the POMs of the publications even when Gradle
metadata is enabled. Note: in the POMs, a project dependency is already
written in the form of the artifact ID of the root Kotlin software
component, so it complicates the dependencies rewriting a little.
To rewrite third-party dependencies, we detect dependencies that
resolved to no artifact and have a single child in the Gradle
dependencies graph of the resolved configuration – this is what a
dependency looks like which was redirected to another module via
'available-at'.
Issue #KT-28482 Fixed
To configure a compilation's sources, we run an action in
`whenEvaluated { ... }`, expecting that the compilation's task already
exists. This was not true with compilations created from a user build
script or a 3rd-party plugin in `afterEvaluate { ... }`.
Fix this by expecting that a task may possibly not exist at that point,
and also using `whenEvaluated { ... }` instead of
`afterEvaluate { ... }` in several places that are executed for each new
compilation as a workaround for
https://github.com/gradle/gradle/issues/1135.
Issue #KT-28896 Fixed
Also update the code for rewriting the dependencies, as Android variants
have their dependencies configurations formed a bit differently, and
also introduce the logic for choosing the right component by the
configuration name the dependency resolves to.
Issue #KT-27535 Fixed
Move the logic of attaching a source JAR to a publication to the
components management part, as building a source JAR will be done
differently for Android.
Instead of exposing a single `component` in a target, allow it to have a
set of `components`, then create a Maven publication for each of the
components.
Move `createUsageContexts` to private API since a target that has
multiple publications may need to create the usage contexts for those
publications differently.
Move some of the components technical stuff to interfaces
`DelegatedToPublication` and
`ComponentWithCoordinatesDelegatedToPublication` in order to reuse it
later for Android's components.
ASM has logic that splits exception tables in MethodWriter.computeAllFrames:
// Loop over all the basic blocks and visit the stack map frames that must be stored in the
// StackMapTable attribute. Also replace unreachable code with NOP* ATHROW, and remove it from
// exception handler ranges.
...
firstHandler = Handler.removeRange(firstHandler, basicBlock, nextBasicBlock);
...
https://gitlab.ow2.org/asm/asm/issues/317867
#KT-28546 Fixed
Proper SMAP support for default values from expect declarations is required.
Default value in expect declaration could has line number that
exceed line count in actual file that causes an error
#KT-23739 Fixed
#KT-29174 Open
Max Medvedev