It started to fail with AssertionError in inlineOnly.kt after
d267f1e875 because "$annotations" methods have annotations from the
corresponding property (which can include InlineOnly), but are never
inline. The test will be unmuted as soon as we stop using wrapped
descriptors in the IR backend to determine access flags which should be
generated on a declaration in the bytecode
Introduce MetadataSource as a way to store the original descriptor for
any element (before any lowerings) and maintain it until the end of the
codegen where it's used in generating the metadata. Note that JVM
signatures written to the metadata are formed from the _resulting_
generated elements, not by mapping the original descriptors.
Some corner cases are not supported yet, namely properties declared in
companion objects, synthetic methods for property annotations,
JvmPackageName, etc.
#KT-29119 Fixed
Move logic regarding expect classes to the only relevant call site at
PackageCodegenImpl, and return the list of members to remove code
duplication at remaining call sites
This is needed to get rid of the code that appends "$companion" to
properties moved from companion, because it caused inconsistencies in
the ABI and in JVM signatures stored in the metadata
For comparison intrinsics and for instanceof checks, make
it possible to get the the stack value produced and branch
on that directly instead of materializing a boolean to
branch on from it.
That reduces code such as
```
IF_CMPEQ L1
CONST_0
GOTO L2
L1: CONST_1
L2: IFEQ L3
```
to just one IF_CMP instruction.
Inline function descriptor in derived class represented as FAKE_OVERRIDE.
So we should find it in base class declaration
(not interface cause inline function can't be virtual, but always final)
and then check class version.
#KT-29402 Fixed
Properties aren't implemented yet
FIR symbol provider functions return more specialized types now
Related to KT-28918, KT-29636, KT-29218
#KT-28788 Fixed
This commit also introduces separate scope processors:
processFunctionsByName and processPropertiesByName, in addition to
existing processClassifiersByName
Ad-hock call resolver starts to discover ambiguities, which leads
to some ambiguity problems in MPP tests with deep supertype hierarchy
Related to KT-29636
This commit prioritizes inner scopes above outer scopes
(before this commit, inner scopes had lowest priority).
NB: really it's not precise enough too,
because explicit importing scope should have higher priority
than inner scopes.
Also fixes problem with total Kotlin resolve test introduced
in previous commit.
Initial member scopes cover top-level, class-level, and supers
Ad-hock version of call resolve was introduced to test them
NB: after this commit, total Kotlin resolve test cannot finish
because of scope problems in type resolve transformer
Related to KT-24078
#KT-24083 Fixed
NpmInstall task adds $nodeModulesDir/package.json to input and fails validation with:
"File '.../package.json' specified for property '$1' does not exist."
Creating javadocJar task for every project produces lots of unnecessary
tasks, some project don't even have code. Jar task without outDir
property set fails idea import with gradle 5.0+
* Due to 'improved POM support' introduced in 5.0, runtime dependencies
of the `compileOnly 'com.android.tools.build:gradle:...'` dependency
were no more transitively available. Add them manually;
* Add `!!` to usages of `resourcesDir`, which became nullable;
* Replace the dropped `classesDir` method usages with reflection;
The generated code is more inline with java, and we avoid the error of
accessing package-private field outside of the package.
However, this changes semantics a bit. Now, a user should set assertion
status of inline-site's package, instead of inline function's one.
#KT-28317: Fixed
There is no Java support in CIDR. Therefore:
- analyze KTS in CIDR using Common platform
- disable error highlighting for KTS in CIDR
Issue #KT-29953 Fixed
Context without expected type became redundant after synthetic
call resolving was added for inference of `if` expression type
`isStatement` flag removed, because it was effectively unused
If kapt is enabled, there are several Kotlin compilation tasks for one source set (stub generator + compile). We should attach the expect sources to all of them.
This also fixes KT-29302 where stub generation is skipped while the
subsequent annotation processing phase anticipates the generated stubs.
This patch addresses cases where kapt.use.worker.api=true. The cases
where kapt.use.worker.api=false are handled in the same place of stub
generation.
The root problem is the fact that ConstantExpressionEvaluator returns
null for values such as infinity and NaN loaded from cls psi (see
IDEA-207252). This commit simply reverts a part of 8ab9226805 where we
started to compute default values more often than needed. In
LazyJavaClassMemberScope, we only need to check whether or not there
_is_ a default value, not compute its value.
#KT-29792 Fixed
This code can be invoked early, during body resolution and before the
fact that a property has backing field (which is only known for certain
after body resolution, because an implicit 'field' identifier may be
used). Since split annotations are cached until the end of the program,
they may end up on incorrect elements in the bytecode (or disappear
completely) as in KT-29507 or KT-28182.
Because the FIELD target has the lowest priority among implicit
annotation targets (see TARGET_PRIORITIES), it's safe to always assume
that FIELD is a valid target when splitting annotations. This only
changes the way annotations are split in case of incorrect code, as
changes in test data show.
#KT-28182 Fixed
#KT-29507 Fixed
^KT-29893 Fixed
Provide AsyncScriptDefinitionsContributor.
Show a notification if the highlighting for script is requested when not all script templates are loaded
In constructs such as 'd[i] += x', where both indexed get and indexed
set are dynamic calls, it's safe to generate augmented assignment body
directly, without temporary variables for array ('d') and index ('i').
Note that corresponding IntermediateValue's are OnceExpressionValue's,
which would throw an exception if this assumption is violated.
NB1 Not every dynamic unary or binary expression is translated to
dynamic operator expressions literally. For example, assignments and
increments can have safe calls in LHS, which require some extra logic.
NB2 There are some open design questions left regarding how dynamic
expressions should actually be translated.
Dynamic expressions are represented as either operator expressions -
e.g., `d1 + d2`, `d[e]`, `d(e1, e2, e3)`, `d += e` -
where "operator" is a one of the known operators,
or as member reference expressions - e.g., `d.memberName` - where
member name is some arbitrary name (unresolved at compile-time and
represented as String).
Apparently function literals are translated without hiding the local declarations
in the wrapFunction call.
Which makes sense. Apart from the fact that it would also make
sense to do the same for private inline functions and function
literals inside other inline functions.
Local aliases can be copied as-is to a different fragment now. Before this change we would have had to extract the local alias tag (if any) from the source fragment and add to the destination fragment name bindings.
The tag generated during the source file translation could differ from
the tag generated based on the import statement (e.g. "intrinsic:..."
during generation becomes "'Kotlin'...." later on).
This means that the same function imported from the start and imported
during inlining has different tags. Which makes duplicate import removal
trickier. The best solution would be to make sure the tag generation
algorithms are consistent.
Current solution: rewrite the tags in terms of the Inliner tag
generation algorithm right after the source file translation.
Also it seems that some `var` statements we treated as imports, even
though they were not. Supported this behavior for now.
TODO: Get rid of these workaround
Module references were stored as plain JsName's. When inlining a function
from one fragment to another, those references should be re-interpreted
in terms of the destination fragment. Storing the whole module information
makes that much easier.
because otherwise language independent bean property references couldn't properly handle rename in some cases.
Groovy references were also affected by this bug because they weren't able to resolve to original property
- Move `prepare/cidr-plugin`, `prepare/clion-plugin` and `prepare/appcode-plugin` modules from `kotlin` to `kotlin-ultimate` project
- Move `versions.clion.*` and `versions.appcode.*` properties from `kotlin` to `kotlin-ultimate` project
- Drop `cidr183` bunch in `kotlin` project
- Drop useless `cidrPluginDir`, `clionPluginDir`, `clionSandboxDir`, `appcodePluginDir`, `appcodeSandboxDir` Gradle properties in `kotlin` project
- Drop `cidrPlugin` Gradle task in `kotlin` project
- Total: Add ability to build `kotlin-ultimate` both as part of multi-project build with `kotlin` project, and as a standalone build
#KT-12700 Fixed
To turn build reports, add 'kotlin.build.report.enable=true' to
gradle.properties file
(or pass it in CLI via`-Pkotlin.build.report.enable=true`).
By default build reports are created in
`rootProject/build/reports/kotlin-build`.
Build report dir can be customized via `kotlin.build.report.dir`
property.
Split the ConstAndJvmFieldPropertiesLowering into two: ConstLowering
which replaces const vals with their values, and
PropertiesToFieldsLowering which removes unnecessary property accessors
(such as for JvmField or private properties with default accessors) and
replaces calls to those accessors with field access
The boundWithSerializableReceiver.kt test is muted since property
references are not yet supported in the JVM IR backend. Previously it
passed by accident
In InnerClassesLowering, the type of the "outer$0" expression should be
the outer class, not the inner class. In EnumClassLowering, the type of
the enum entry is the type of its class or the type of the enum class,
but not the type of initialierExpression which is always Unit
IrDeclarationOrigin.FILE_CLASS is used in CallableReferenceLowering to
generate correct declaration owner.
Many reflection tests start to fail with this commit because they are
now treating callable references to top level declarations as Kotlin
symbols and fail because there's no JVM signature for them; this is
fixed in subsequent commits (previously, they worked because without
Kotlin metadata, these files were treated as Java classes)
After one of previous commits (my or Mikhail Zarechenskiy) that test
was broken and it's behaviour was not fixed. That test's behaviour
is strange (why at one case we have `UNREACHABLE_CODE` and haven't
at other) and needs further investigation
CLITool.exec is used in konanc to perform compilation of native project.
Due to some internal limitation, this function runs in separate process.
After this change, there will be a possibility to choose MessageRenderer
used in CLITool.exec via system property
org.jetbrains.kotlin.cliMessageRenderer.
Reviewed at KOTLIN-CR-2698.
In Gradle 5.2 the 'WrapUtil.toNamedDomainObjectSet' method
was removed. This patches replaces usage of this method
with call of the 'Project.container' method.
Issue #KT-29725 Fixed
Code such as
```
val b = getBoolean()
if (b) 4
else if (b) 5
```
didn't generate a value on the stack always and therefore would
have control-flow paths leading to a pop instruction with nothing
on the stack.
Change-Id: I09d059f361e56a41880006e3f4e51e9acdbd167d
Initializers are "set field" expressions and are considered redundant
when they are:
1. In the primary constructor; and
2. Set the field to `0`, `false`, or `null`; and
3. Have a `null` origin. I.e., not in an initializer block or
constructor body, and therefore the field could not have been set by a
prior expression.
Add some classes to hierarchy of `ESValue`:
- `ESReceiver` -- representation of receiver
of lambda function
- `ESDataFlow` and `ESDataFlowReceiver` -- little refactoring of entities
that holds information for DFA (description in comments in code).
Also add kdoc to classes of `ESValue` hierarchy
Previously only `VariableDescriptor` was key of `ControlFlowInfo`.
Now it's generic parameter `K: Any`, so there is a possibility of using
different object's inside CFA
There is two methods added into `AbstractLoadJavaTest`:
- `configureEnvironment(KotlinCoreEnvironment environment)` allow to
configure environment that will be used two compilation of source test
data and loading generated `.class` files (e.g. you can register extensions)
- `getExtraClasspath()` allow to add custom libraries to classpath of
compiler
Similar methods exists in `AbstractDiagnosticsTest`
Earlier the K/N platform libraries were looked for in a local ivy
repository created on basis of a K/N compiler distribution. Such
an approach allowed correctly showing such dependencies in
IDEA using the "group:name:version" format (e.g.
"Kotlin/Native:Accounts:ios_arm64:1.1.1"). But it caused looking
for there libraries in all other declared repositories too
making IDE import slower (see KT-28128).
This patch declares these dependencies as files and gets rid of
the local repo to avoid this problem. The downside of this change
is less informative output in the IDE:
"Kotlin/Native:Accounts:ios_arm64:1.1.1" -> "Accounts".
Issue #KT-28128 Fixed
When the plugin rewrites a POM, it establishes the mapping of the
original Maven coordinates to the modified ones. As one of the steps,
this requires finding the original Maven coordinates to rewrite – these
should be exactly the coordinates that Gradle writes to the POM.
In MPP, these are the coordinates of the 'root' (Gradle module metadata)
publication. If those are modified in the publication, the plugin relies
on delegating to the publication in the root module's SotwareComponent
(the only reasonable fallback is the project's name, and in this case
it obviously doesn't match the Maven artifact ID that was modified).
In 1.3.20, the publication delegate was never assigned. To fix the
issue, it is enough to correctly assign the publication delegate for the
root module's SoftwareComponent.
Issue #KT-29485 Fixed
* Add the extendsFrom relation between the Kotlin MPP compilation's
configurations (`*Api`, `*Implementation`, `*RuntimeOnly`) and
the Android variant's `*Elements` configurations, as those
dependencies currently are not added to the Android source sets and
are thus missing from the published dependencies.
* Fix a `this is KotlinCompilationToRunnableFiles` check that
mistakenly referenced the Project receiver of `whenEvaluated { ... }`
Issue #KT-29476 Fixed
Setting `forkMode` to `ForkMode.NEVER` switches
`isolationMode` to `IsolationMode.CLASSLOADER`.
Classloader isolation mode prevented passing task's
logger to the unit of work.
Also it might resulted in multiple daemon instances starting
in parallel.
This change removes setting `forMode` (it was unnecessary).
Also a logger is used for the fallback message instead of printing it
to stderr. An assertion is added to tests, ensuring that
the fallback does not happen.
#KT-29394 Fixed
In general case, the module where built-ins are looked up
(builtInsModule) can have multiple package fragments corresponding to
the package "kotlin". Remove the misleading method
getBuiltInsPackageFragment along with its implementation details and use
the package view's scope instead (by changing
KotlinBuiltIns.getBuiltInsPackageScope), since it'll iterate over all
fragments accessible in the module and its dependencies.
The only difference between scopes of package fragment and package view
is that the latter also contains package views for subpackages, which is
why the change in BuiltInsReferenceResolverTest is necessary
Default built-ins represent built-ins loaded from the compiler jar via
class loader, and they may not be equivalent to the built-ins present in
the standard library that is used in compilation dependencies, in case
the compiler and stdlib versions do not match. Use built-ins from the
given module instead.
This commit deals with more-or-less obvious usages of DefaultBuiltIns;
next commits refactor the ESConstant values and related code to support
injected built-ins
Instead use a filter with a simple check. This seems to be slightly
better both for readability (`strictPartition` gave an impression that
two its parameters were related in some way, but they were totally
independent) and for performance (do not create unnecessary objects,
instead decompose the existing objects and check their structure)
- refactor appropriate functions to accept optional classloader (not used yet)
- try to load from thread context classloader first
- fallback to marker class classloader in the appropriate function
This script traverses all Gradle copy task, build virtual files model
and generates IDEA artifacts configuration based on this. Unfortunately
this is not fully working and needs manual fixing, so the actual artifacts
configurations are commited by hand for now. By the way, this script also
visits copy task's internals which leads that Gradle generates
manifests in `build` folders during IDEA import. This files are referenced
in artifacts configurations. So, despite the fact that artifacts
configurations created by this script is not used, we need to run them
to generate required manifests.
This solution will be replaced with DSL that produces both Gradle
copy tasks and IDEA artifacts configuration which is coming soon.
Simplify MultifileClassPartCodegen, remove related tests and change some
tests to use const val instead of val because backing fields for const
properties are stored in the facade, not parts
#KT-23701 Fixed
In JDK 9, Class.simpleName changed behavior for local/anonymous Kotlin
classes (see KT-23072), this is why we now check for both variants of
the name in tests. Also, the format of annotation arguments changed a
little, where float parameters no longer have the trailing "f", and
class literals are rendered with ".class" at the end
Bypass builtins deserialization mechanism in legacy JS backend and load
bultins direcly as kotlin code.
This way we won't have separated IR declarations for Enum, Char, Long
Some "native" builtins are implemented in libraries/stdlib/js/irRuntime/builtins/
Other builtins are moved by MoveExternalDeclarationsToSeparatePlace and
used only in compile-time
Move the hint to the end of the line, to avoid breaking indentation.
Also use `EditorLinePainter` API for painting to prevent problems with
typing at the line end, when caret is placed after the hint
(See IDEA-204702 for implementing such hints in platform).
#KT-28870 Fixed
Now both of those classes implements one interface with `TypeProjection`
property. That allows old captured type approximator use new captured types.
That change fixes tests related to diagnostics:
- SETTER_PROJECTED_OUT
- DEBUG_INFO_UNRESOLVED_WITH_TARGET
- UNRESOLVED_REFERENCE_WRONG_RECEIVER
Also `typeProjection` property renamed to `projection` according to naming in NI.
That commit fix next diagnostics:
* RECEIVER_NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS
* NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS (partially, see #KT-29367)
#KT-12295 Fixed
Gradle forces non-incremetnal builds,
when a task failed, but its outputs were changed.
This is an issue for Kotlin incremental compilation,
because it also forces all dependent modules to be rebuilt.
This change fixes the issue by reading all output and
restoring it on a compile error/exception.
This change does not affect non-incremental builds.
Simplify ifs when branches have condition true/false.
Simplify blocks containing only a variable declaration
and a variable get of the same variable. Simplify to
just the condition.
Do not introduce temporary variables for constants for
null checks. Constants have no side-effects and can be
reloaded freely instead of going through a local.
This simplifies code such as "42.toLong()!!" so that the
resulting code has no branches and uses no locals. The
simplifications happen as follows:
```
block
temp = 42.toLong()
when
(temp == null) throw NPE
(true) load temp
---> null test simplification
block
temp = 42.toLong()
when
(false) throw NPE
(true) load temp
---> when simplification
block
temp = 42.toLong()
load temp
---> block simplification
42.toLong()
```
consoleView field is initialized in initAndRun inside invokeLaterIfNeeded call.
This may cause NPE in setupGutters if consoleView isn't initialized yet
^KT-29400 Fixed
* if enum class has abstract members, then it is ABSTRACT
* otherwise, if enum class has entries with members, then it is OPEN
* otherwise, it is FINAL.
In case of the same class defined in different modules they contain
different descriptors instances in their scope that might lead
to failing assertion in findConcreteSuperDeclaration
because there are overridden from different modules
It might happen even in the compiler because of different built-in modules
defined for sources-module and for dependencies' one
^KT-29320 Fixed
On windows using a project's root
as a working directory for the daemon
seems to prevent removing the directory
when the daemon runs.
Different projects may share an instance of the daemon,
so the issue will be present only in a project
which started the daemon.
In super class constructor arguments, 'this' can be resolved
as a reference to a companion object of a superclass.
This breaks an assumption in psi2ir that 'this' can only refer to some
receiver from the current scope.
If 'this' refers to an 'object' (including 'companion obejct'),
and we are not inside the corresponding class scope,
then 'this' represents a reference to a singleton instance "by name"
(represented as IrGetObjectValue).
Introduce lowering to remove null checks for primitive type
expressions and replace them with true/false. Side-effects
are preserved.
Generate ifnull/ifnonnull instructions for null checks instead
of materializing a null literal for an equality check.
and use proper default evaluation configuration if not supplied explicitly;
also add reset method to the properties builder and containsKey method to
the properties collection
#KT-29296 fixed
Before the fix for KT-7185, the file looked like:
package suppression
@file:Suppress("UnusedImport")
import java.io.* // unused
And it was parsed incorrectly, because @file: annotations
should come before package directive
But after fix, import directives started being parsed that lead
to wrong unused import (because suppression wasn't parsed still)
The case for KT-7237 belongs to /NoGTInTypeArguments test
It was fixed implicitly: before it recovery was working but the name for
the next parameter was attached to type argument list.
After that change, parameter without name gets parsed correctly (with an
error of course)
^KT-13731 Fixed
^KT-7237 Fixed
This fix is work-around fixing incompatibility issue between gradle
tooling api bundled in IDEA and gradle tooling api in gradle 4.x.
When null messages were logged it resulted in the following error:
"java.io.StreamCorruptedException: invalid stream header: ED000573"
Consider following expression: 'call() is Foo'. Suppose that we know
something about the 'call()', e.g. 'returns(foo) -> <condition>'
Previously, we've tried to re-use knowledge about 'call()', constructing
some smart clause, like 'returns(true) -> foo is Foo && <condition>'.
The conceptual error here is that *we can't* argue that <condition>
holds. Imagine that 'call()' actually has unspecified 'returns(foo2) ->
<!condition>', and 'foo2 is Foo' also holds. Then we would get
'returns(true) -> foo2 is Foo && <condition>' <=> 'returns(true) ->
<condition>' for the whole call, which is not correct.
More concrete example would be something like:
'if (!x.isNullOrEmpty() is Boolean)'
^KT-27241 Fixed
1. There is no need to specify repositories.
2. We don't use 'org.jetbrains.kotlin:gradle-api:1.6' anymore.
3. kotlin-serialization-unshaded does not need dependencies,
because it does not contain source code (it simply packages jar).
AGP 3.0.x requires explicit 'kapt' dependency on databinding compiler.
Also databinding v2 (enabled by default in AGP 3.2.0) generates different
java classes.
Bridge function should be created when return type of override function
is specialised to unboxed inline class. Thus return type should be used in
function signature.
Non-inline-class return types are not added to signature for interop and
infrastructure reasons ("toString" would become "toString_ret$kotlin_String")
Use signature of function 'target' (a real function that will
be called instad of fake override) to make boxing/unboxing decision for
return value and type parameters on call site.
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
Previously `findJavaRootDescriptor` was return source root for random
module. This cause build errors for mpp (same file may appear in
multiple source roots of common and platform modules)
#KT-28988 Fixed
In 1.3.0 there was introduced KT-28061 bug, which caused some of the
NO_RETURN_IN_FUNCTION_WITH_BLOCK_BODY diagnostics to be lost (turning
"red" code into "green")
500dc11514 fixes the bug and returns
lost diagnostics back. This commit adds additional information for some
of the cases where diagnostics were list and then brought back (for the
user sanity).
The heuristic used for detecting cases which need additional information
is simple: if function has return in in-place called lambda, and
NO_RETURN_IN_FUNCTION_WITH_BLOCK_BODY should be reported, then we
enhance it with additional information.
^KT-28061 Fixed
Rewrite CharArray to String conversions to appending chars one by one.
Refine parameter checking in String(chars, offset, length) to adhere to
the common exception contract and document it.
#KT-29003
Without the introduced override, default implementation of isEquivalentTo
runs delegate computation of `another` that is illegal
for KtUltraLightClass
^KT-28912 Fixed
In 2010b175, it was suggested just not to suggest parentheses removal.
However, it contradicts with behaviour of "Replace contains" which
adds semicolon before lambda in this case. So in this commit I made
behaviour of remove parentheses the same.
This commit reverts production part of 2010b175
Fixes failing test of "replace contains"
Main test data (testName.txt) a not totally valid cause of IDEA-205039.
Javac test data (testName.javac.txt) a not valid
cause of type annotations support absence.
Runtime tests are disabled cause reflection support absence.
Introduce lowering phase that turns !!exp -> exp for the boolean
'not' builtin. This makes sure that code such as
```
if (!!!!!booleanValue) {
doStuff()
}
```
generates only one branch.
Original problem is that lowered ir closures doesn't meet inliner expectations
about captured variable position in inlining method.
E.g.: Call 'foo(valueParam) { capturedParam }' to
inline function 'foo' with declaration
inline fun foo(valueParam: Foo, inlineParamWithCaptured: Bar.() ->) ....
is reorganized through inlining to equivalent call foo(valueParam, capturedParam1, cp2 ...).
But lowered closure for lambda parameter has totally different parameters order:
fun loweredLambda$x(extensionReceiver, captured1, cp2..., valueParam1, vp2...)
So before inlining lowered closure should be transformed to
fun loweredLambda$x(extensionReceiver, valueParam1, vp2..., captured1, cp2..)
#KT-28547 Fixed
In general case parameter type could differ from actual default lambda type.
E.g.: fun inlineFun(s: (Child) -> Base = { a: Base -> a as Child}),
where type of default lambda is '(Base) -> Child'.
In such case we should find somehow actual invoke method in bytecode knowing
only name, number of parameters and that's actual invoke is non-synthetic
regardless of bridge one.
#KT-21946 Fixed
Since these tests compile Kotlin code against compiled Java code, it's
only reasonable to use the same .class file reading implementation as is
used in production for the same purpose
Before this commit, only one-line enums and annotation classes were
considered. Now we can have enum header on one line and
some entries on another lines, and it still works.
Same with primary constructor parameters.
#KT-22637 Fixed
- Allow to select target platform and target directory to generate source for
- Put copyright profile to resources to have it in the resulting jar
- Output error for missing bodies, but do not stop generation on the first error
CommonDataKeys.EDITOR key isn't present for some events (for example when user click on isRepl checkbox on scratch panel or there isn't any file open in the editor)
^KT-28045 Fixed
Laziness works no more in this tests after dummyContextProvider is removed
for script light classes (see fix of KT-25395).
However, now 2/2 script light classes tests still fail in IDE mode,
because after fix of KT-26505 IDE light classes do not see
ScriptTemplateWithArgs as super-class
Before this commit, we used script context for all classes
defined in script. However, for local classes in scripts it's mistake,
and now we generate them as usual, despite of the fact we are in script.
#KT-28997 Fixed
Add 'coreLibs*' aggregate tasks for 'clean', 'assemble', 'install'
and 'dist' tasks of core libs projects.
Remove '-jre7/8' libs from the list of core libs.
ScriptModuleInfo for scripts outside source roots in compared by virtualFile and script definition.
So when we use ScriptDefinitionsManaged.getDefaultScriptDefinition we shouldn't create a new one on each call
EA-132810 - assert: DiagnoseUnknownModuleInfoReporter.report
Since 183 changes in .gradle.kts files are tracked correctly by platform and notification 'Gradle project needs to be imported' is shown when those files are modified
Project.getLanguageVersion with contextModule == null returns latest stable version.
But Module.getLanguageVersion save it's version to project setting if useProjectSettings checkbox is selected.
So Project.getLanguageVersion can return different versions before and after invocation Module.getLanguageVersion
For the inline class:
```
inline class IC(val x: Int)
```
Type (IC..IC?) should be mapped to the wrapper `IC`
because it can hold object and also because it does so for primitives
#KT-28983 Fixed
All bytecode text tests are run with stdlib in the classpath and only
for JVM backend, therefore directives WITH_RUNTIME, TARGET_BACKEND,
IGNORE_BACKEND are not needed
Test data of crossinline_1_2.txt has changed because now we do not
automatically enable 1.2 (with _all_ of its features) when we're
executing a common coroutines test with old coroutines; and so the
NewCapturedReceiverFieldNamingConvention language feature (which is
introduced in 1.3) is now enabled in this test
Use `// !LANGUAGE: -ReleaseCoroutines` instead in tests which require
old (1.2) coroutines, and nothing in tests which require new coroutines
because master is already 1.3. Also remove superfluous API_VERSION and
other directives which have no effect anymore. Do not include runtime
automatically with `WITH_COROUTINES`/`COMMON_COROUTINES_TEST` in box
tests; require `WITH_RUNTIME` for that (majority of tests already had it
anyway), but remove it from bytecode text tests where runtime is always
added automatically. Fix the coroutine package selection code in
KotlinTestUtils and update the bunch files correspondingly.
Disable tests in `box/coroutines/noStdLib` on JVM: despite the name,
these tests were launched with stdlib because of the code in
CodegenTestCase, and they do not work without it because at least
CoroutineUtil.kt requires stdlib to compile correctly
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
See `ExpressionCodegen.genEqualsForExpressionsPreferIeee754Arithmetic`:
the behavior here actually depends on the API version, not any language
feature
- Drop unnecessary bunch files for `KotlinFacetType` and `KotlinFacetTypeImpl`
- Use cached val `isRunningInCidrIde` to check if the code is running under CIDR
#KT-28836 fixed
RMI messages are reported from RMI threads.
When Gradle logger is used from non-Gradle thread,
messages are not grouped in command-line
and they are not shown in build scans.
To fix this, we store all messages from Kotlin daemon
in a buffer, then report them from a Gradle thread.
In 1.3.0 only basic settings for final native binaries (e.g.
executables or frameworks) are available. They allow a user to
specify what kinds of binaries should be produced from one or another
compilation but they don't allow specifying different options for
different binaries or creating more than 2 (debug and release)
binaries of the same kind (e.g. executable) from the same
compilation. Also link tasks for these binaries are created after
project evaluation thus they are inaccessible for a user outside
of an afterEvaluate block.
This patch adds an extended binary DSL allowing a user to declare
binaries independently from compilations and to specify different
options (e.g. linker arguments) for different binaries. Also
link tasks for binaries declared in this DSL are created at a
configuration time so user can access them outside of an
afterEvaluate block.
Also this patch adds creating run tasks for all executables
declared in the buildscript (KT-28106)
Initial DSL methods for binaries declaration are still supported.
Kotlin DSL example is the following:
kotlin {
macosX64 {
binaries {
// Create debug and release executable with
// a name prefix 'Foo'.
// Two domain objects will be created:
// fooDebugExecutable and fooReleaseExecutable
executable("Foo", listOf(RELEASE, DEBUG)) {
compilation = compilations["foo"]
entryPoint = "foo.main"
linkerOpts.add("-Llib/path")
println(runTask.name)
}
// Name prefix and build types are optional.
// debugFramework and releaseFramework are created here.
framework()
}
}
}
It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
In Gradle 4.10.2, a change was made in the attributes disambiguation
process: if some of the candidates have a single attribute value and
others don't have that attribute (i.e. have a null value), the
disambiguation rule for that attribute doesn't get called.
Effectively, null values are excluded from disambiguation, but still may
cause ambiguity (sic!)
See: https://github.com/gradle/gradle/issues/6747#issuecomment-445921139
This change affected our attribute `localToProject` that we use to
disambiguate the deprecated but still consumable configurations like
`compile`, `runtime`, `testCompile`, `testRuntime` from those
configurations which should have priority during project dependency
resolution: the `*Element` ones. Our scheme marked the former
configurations with the attribute and the latter were not marked, with
a disambiguation rule that preferred null values.
To fix this logic with Gradle 4.10.2, we instead mark both kinds of
configurations with the attribute, which now has a value 'public'
that is preferred by the rule over the other values. We also make sure
that the attribute doesn't leak into the published Gradle metadata, as
it is only needed for project-to-project dependencies resolution.
Issue #KT-28795 Fixed
In Gradle 5.0, iterating over the `.withType<...>()` result below
caused a ConcurrentModificationException. Workaround that by first
collecting the items into a list.
* Introduce GradleVersionRequired.InRange and thus prevent older
tests (e.g. Android 2.3.0) from running with newer Gradle versions
* Add a task outputs pattern suitable for Gradle 5.0
* Run some of the Android tests with AGP 3.1.0 (and Gradle 4.4) instead
of 3.0.0 to ensure compatibility with Gradle 5.0
* Update test projects according to Gradle 5.0 dropped deprecated
features: classesDir, left-shift operator, default org.gradle.util.*
imports
* Fix a Gradle test after Gradle 5.0 changed `publishing` behavior to
run the closure eagerly rather than after evaluation
AP discovery in compile classpath can be disabled in all subprojects
by adding "kapt.include.compile.classpath = false" to 'gradle.properties' file.
KT-24530
The setting can be overrided per project by using KAPT DSL
in a 'build.gradle' file:
```
kapt {
includeCompileClasspath = false
}
```
#KT-28852 fixed
The loaders and hence some classes were repeatedly loaded and
jit-compiled everytime when KaptExecution were dispatched. Those
classes, like JavaCompiler, can be very large and therefore created a
significant overhead. In some projects, the overhead accounted for more
than 40% of total CPU time of annotation processing.
This change tries to cache the classloaders so that they won't be
reloaded and re-jitted.
The compiler uses thread local values,
so when the compiler runs Gradle's thread,
it leaks classes preventing
a compiler's classloader from being collected.
#KT-28037 fixed
In cases when kapt compiler plugin runs in stubs generation mode,
Java usage tracker was not completed. This caused issues with
the incremental compilation if Java files changed.
E.g. if a constant defined in Java source file changed, stubs
would not be recompiled because the Java usage tracker would
not report changed type. This commit fixes that issue.
Instead of trying to access a missing field `Foo.foo`, call the
synthetic accessor `Foo.access$getFoo$cp` which, as per previous commit,
no longer contains the lateinit assertion
#KT-21862 Fixed
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
#KT-25128 Fixed
ABI class generation is implemented as a compiler plugin.
Command-line usage:
1. Add a path to 'jvm-abi-gen.jar' to the plguin classpath argument
(`-Xplugin`). By default the jar is located at
'kotlinc/lib/jvm-abi-gen.jar' in the kotlinc distribution archive.
2. Specify an output directory for ABI classes via
`-Pplugin:org.jetbrains.kotlin.jvm.abi:outputDir=<DIR>`.
This fixes the most common (and rather annoying) bug in augmented
assignment desugaring with collection element receiver.
Fix is somewhat hackish: introduce an intrinsic for MutableMap.set,
thus bypassing discrepancies in 'get' and 'set' call generation.
Fixing it properly requires design decisions for corner cases where
ad hoc augmented assignment desugaring with collection element receiver
"accidentally" works, producing identical objects and vararg arrays for
arguments of 'get' and 'set'.
Input and output types are crucial for type variable fixation order and
analysis of postponed arguments (callable references, lambdas).
Specifically, if there is non-fixed type variable inside input types of
a callable reference, then we'll postpone resolution for such callable
reference.
Initial example with the expected type `KMutableProperty1<*, F>` caused
problems because input types were computed incorrectly (while there
aren't input types here)
#KT-25431 Fixed
It's needed to estimate the count of steps for type approximation algorithm.
After the estimated count of steps, we consider such type recursive and this
algorithm returns some default value
#KT-28598 Fixed
<Problemreference="com.intellij.openapi.progress.ProgressManager#getProgressIndicator"reason="Not null starting from 181. Use getProgressIndicatorNullable instead."/>
<Problemreference="com.intellij.testFramework.PlatformTestCase#createModuleAt"reason="Not static anymore in 181 after 7dacf096c47d2125e17031c71a037b63ab00ec53"/>
<Problemreference="com.intellij.testFramework.PlatformTestCase#doCreateRealModuleIn"reason="Not static anymore in 181 after 7dacf096c47d2125e17031c71a037b63ab00ec53"/>
<Problemreference="com.intellij.openapi.progress.ProgressManager#getProgressIndicator"reason="Nullable in 181. Temporary use progressIndicatorNullable instead."/>
<Problemreference="org.jetbrains.java.decompiler.main.decompiler.BaseDecompiler#addSpace"reason="Method was replaced with outher methods in 182. Use addSpaceEx instead."/>
<Problemreference="com.intellij.psi.codeStyle.CommonCodeStyleSettings#copyFrom"reason="Absent in 173. Use CompatibilityKt.copyFromEx instead."/>
<Problemreference="com.intellij.psi.codeStyle.CommonCodeStyleSettingsManager#copy"reason="Removed since 181. Use CompatibilityKt.copyFromEx instead."/>
<Problemreference="com.intellij.notification.NotificationAction#createSimple"reason="Absent in 173."/>
<Problemreference="com.intellij.notification.NotificationAction#create"reason="Absent in 173."/>
<Problemreference="com.intellij.util.JdomKt#element"reason="Removed in 191"/>
<Problemreference="com.intellij.execution.JavaRunConfigurationExtensionManager#getInstance"reason="Can't be used in Kotlin, because method was replaced with property after J2K in 183. Use JavaRunConfigurationExtensionManagerUtil instead."/>
<Problemreference="org.jetbrains.java.decompiler.main.decompiler.BaseDecompiler#addSpace"reason="Method was replaced with outher methods in 182. Use addSpaceEx instead."/>
<Problemreference="com.intellij.util.JdomKt#element"reason="Removed in 191"/>
<Problemreference="com.intellij.execution.configurations.RunConfigurationBase"reason="Generalized in 183. Use RunConfigurationBaseAny instead in signatures."/>
<Problemreference="com.intellij.execution.configurations.LocatableConfigurationBase"reason="Generalized in 183. Use LocatableConfigurationBaseAny instead in signatures."/>
<Problemreference="com.intellij.execution.configurations.ModuleBasedConfiguration"reason="Generalized in 183. Use ModuleBasedConfigurationElement instead."/>
@@ -116,6 +108,19 @@
<Problemreference="com.intellij.testFramework.codeInsight.hierarchy.HierarchyViewTestFixture"reason="Absent in <= 181. Use org.jetbrains.kotlin.test.HierarchyViewTestFixture instead."/>
<Problemreference="org.jetbrains.kotlin.test.HierarchyViewTestFixtureCompat"reason="Do not use the wrapper for 181 directly. Use org.jetbrains.kotlin.test.HierarchyViewTestFixture instead."/>
<Problemreference="com.intellij.psi.codeStyle.CodeStyleSettingsProvider"reason="Additional method is introduced in 183 instead of deprecated one. Use CodeStyleSettingsProviderCompat instead."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#getExtensionList()"reason="Absent in 182 and before."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#extensions()"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#hasAnyExtensions"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#getExtensionList(com.intellij.openapi.extensions.AreaInstance)"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#extensions(com.intellij.openapi.extensions.AreaInstance)"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#getPoint"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.extensions.ExtensionPointName#findExtensionOrFail"reason="Absent in 182."/>
<Problemreference="com.intellij.openapi.ui.popup.PopupChooserBuilder#PopupChooserBuilder(javax.swing.JList)"reason="Generified in 182. Use PopupChooserBuilderWrapper instead."/>
<Problemreference="com.intellij.openapi.editor.event.EditorFactoryListener"reason="Default implementations were added in 183. Use EditorFactoryListenerWrapper for inheritance instead."/>
<Problemreference="com.intellij.codeInspection.reference.RefFile#getPsiElement"reason="Absent in 182. Use psiFile extension instead."/>
<Problemreference="com.intellij.openapi.diagnostic.LoggerKt#debugOrInfoIfTestMode"reason="Absent in 182."/>
<Problemreference="com.intellij.psi.search.PsiSearchHelper#getInstance"reason="Absent in 181. Use psiSearchHelperInstance() instead."/>
<Problemreference="com.intellij.psi.search.PsiSearchHelper.SERVICE"reason="Deprecated since 182. Use psiSearchHelperInstance() instead."/>
This project and the corresponding community is governed by the [JetBrains Open Source and Community Code of Conduct](https://confluence.jetbrains.com/display/ALL/JetBrains+Open+Source+and+Community+Code+of+Conduct). Please make sure you read it.
* [TeamCity CI build](https://teamcity.jetbrains.com/project.html?tab=projectOverview&projectId=Kotlin)
## Editing Kotlin
@@ -83,7 +83,7 @@ Refer to [libraries/ReadMe.md](libraries/ReadMe.md) for details.
### Building for different versions of IntelliJ IDEA and Android Studio
Kotlin plugin is indented to work with several recent versions of IntelliJ IDEA and Android Studio. Each platform is allowed to have a different set of features and might provide a slightly different API. Instead of using several parallel Git branches, project stores everything in a single branch, but files may have counterparts with version extensions (\*.as32, \*.172, \*.181). The primary file is expected to be replaced with its counterpart when targeting non-default platform.
Kotlin plugin is intended to work with several recent versions of IntelliJ IDEA and Android Studio. Each platform is allowed to have a different set of features and might provide a slightly different API. Instead of using several parallel Git branches, project stores everything in a single branch, but files may have counterparts with version extensions (\*.as32, \*.172, \*.181). The primary file is expected to be replaced with its counterpart when targeting non-default platform.
More detailed description of this scheme can be found at https://github.com/JetBrains/bunches/blob/master/ReadMe.md.
We love contributions! There's [lots to do on Kotlin](https://youtrack.jetbrains.com/issues/KT) and on the
[standard library](https://youtrack.jetbrains.com/issues/KT?q=%23Kotlin%20%23Unresolved%20and%20(links:%20KT-2554,%20KT-4089%20or%20%23Libraries)) so why not chat with us
about what you're interested in doing? Please join the #kontributors channel in [our Slack chat](http://slack.kotlinlang.org/)
and let us know about your plans.
If you want to find some issues to start off with, try [this query](https://youtrack.jetbrains.com/issues/KT?q=tag:%20%7BUp%20For%20Grabs%7D%20and%20State:%20Open) which should find all open Kotlin issues that are marked as "up-for-grabs".
Currently only committers can assign issues to themselves so just add a comment if you're starting work on it.
A nice gentle way to contribute would be to review the [standard library docs](https://kotlinlang.org/api/latest/jvm/stdlib/index.html)
and find classes or functions which are not documented very well and submit a patch.
In particular it'd be great if all functions included a nice example of how to use it such as for the
This is implemented using the [`@sample`](https://github.com/JetBrains/kotlin/blob/1.1.0/libraries/stdlib/src/kotlin/collections/Maps.kt#L91)
macro to include code from a test function. The benefits of this approach are twofold; First, the API's documentation is improved via beneficial examples that help new users and second, the code coverage is increased.
Some of the code in the standard library is created by generating code from templates. See the [README](libraries/stdlib/ReadMe.md) in the stdlib section for how to run the code generator. The existing templates can be used as examples for creating new ones.
Also the [JavaScript back-end](https://github.com/JetBrains/kotlin/blob/master/js/ReadMe.md) could really use your help. See the [JavaScript contribution section](https://github.com/JetBrains/kotlin/blob/master/js/ReadMe.md) for more details.
If you want to contribute a new language feature, it is important to discuss it through a [KEEP](https://github.com/Kotlin/KEEP) first and get an approval from the language designers. This way you'll make sure your work will be in line with the overall language evolution plan and no other design decisions or considerations will block its acceptance.
## Submitting patches
The best way to submit a patch is to [fork the project on GitHub](https://help.github.com/articles/fork-a-repo/) and then send us a
[pull request](https://help.github.com/articles/creating-a-pull-request/) via [GitHub](https://github.com).
If you create your own fork, it might help to enable rebase by default
when you pull by executing
``` bash
git config --global pull.rebase true
```
This will avoid your local repo having too many merge commits
which will help keep your pull request simple and easy to apply.
## Checklist
Before submitting the pull request, make sure that you can say "YES" to each point in this short checklist:
- You provided the link to the related issue(s) from YouTrack
- You made a reasonable amount of changes related only to the provided issues
- You can explain changes made in the pull request
- You ran the build locally and verified new functionality
- You ran related tests locally and they passed
- You do not have merge commits in the pull request
Please be sure to review Kotlin's [contributing guidelines](docs/contributing.md) to learn how to help the project.
sourcePathisFileTreeAdapter&&sourcePath.treeisGeneratedSingletonFileTree->ctx.child("FILE TREE ADAPTER OF MAP FILE TREE (${sourcePath.javaClass.simpleName})"){child->
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
