KotlinProjectStructureMetadata is created by inspecting source sets
with metadata compilation. Single backend common source sets are
currently not supported for metadata compilation and therefore
did not register one. Foreseeing to support this case with KT-42468,
metadata compilation is now created and registered, but just disabled.
This change will include android variants in
KotlinProjectStructureMetadata even when not officially published.
With those variants, the IDE can infer visibility from some module's
"jvmAndAndroidMain" source set to another modules "jvmAndAndroidMain"
KotlinMetadataTargetConfigurator: rename getPublishedCommonSourceSets to getCommonSourceSetsForMetadataCompilation
KotlinMetadataTargetConfigurator: isMetadataCompilationSupported and add comment to getPublishedCommonSourceSets
Re-use androidPluginIds in KotlinPlugin
KotlinAndroidTarget: Create KotlinComponents for non-published variants and mark them with publishable=false
JvmAndAndroidIntermediateSourceSetTest: add KotlinProjectStructureMetadata jvmAndAndroidMain exists in jvm variants test
AbstractAndroidProjectHandler: Add java sources only in post processing
KotlinAndroidTarget: Inline creation of usageContexts
KotlinAndroidTarget.doCreateComponents: filter non-publishable variants when publishLibraryVariantsGroupedByFlavor is enabled
#KT-42383 fixed
Previously, when adding --warning-mode=fail to KaptIncrementalIT,
it would fail when testing with advance gradle version because
deprecated configurations in build files of test projects and
gradle api usage in artifact transform.
With this PR, we have two "StructureTransformAction'. The one with
latest gradle api is for use at most cases, the legacy one is for use
when gradle version is less or equal than 5.3 because the new gradle api
is introduced in 5.4.
This change also adds some test fixtures and updates deprecated
configurations to support testing artifact transform.
Test: KaptIncrementalIT
It was changed in order to support build cache for K/N tasks but as we doesn't support cache for CInteropProcess task at the moment, there is no overlapping outputs issue
#KT-43080 Fixed
AbstractKotlinTarget#buildAdhocComponentsFromKotlinVariants passes a
non-serializable local object to a lambda, which will fail during
serialization when configuration caching is enabled.
To fix that, this commit passes only the relevant parts of the object
to the lambda.
Bug: https://youtrack.jetbrains.com/issue/KT-43054
Test: Manually verified on
https://android.googlesource.com/platform/tools/metalava/+/refs/heads/master/
where the issue was detected (I haven't been able to create a mininal
reproducible project)
Updated KDoc generator template to address all instances of
a grammatical error ("less" -> "fewer").
Also committed newly generate _Collections.kt, _Sequences.kt,
and _Strings.kt.
This allows the files to survive Gradle's `clean` task that deletes the
`build/` directory with all its contents, which leads to the IDE losing
dependencies until next re-import.
The `.gradle` directory is chosen because Gradle creates it in every
project and it is normally included in .gitignore (or otherwise ignored
in VCS).
Related to issue #KT-39568
- Adjust implementations to avoid excessive vararg copies
- Remove options from forEachLine, it doesn't make much sense and
isn't consistent with the other read* functions.
- Revise inlineness of functions in PathReadWrite
- Compact implementations of those that are remained inline.
- Clarify docs of functions for reading the entire file
#KT-19192
Delegate most checks to the platform Files.copy.
This changes the exception type thrown in one case,
so document when it happens. Also 'copyTo' no longer
creates target parent directory if it doesn't exist.
#KT-19192
This PR adds most extensions on `java.io.File` in `kotlin.io` to `java.nio.Path`. This includes extensions from `FileReadWrite.kt`, `Utils.kt`, and `FileTreeWalk.kt`.
I attempted to keep the implementations, documentation, and tests as similar as possible to the existing implementations.
I am happy to add, remove, or move to separate PRs any of the functions of this PR.
### `File` extensions that were not added to `Path`
##### `createTempDir`, `createTempFile`
These functions have no `File` parameters, so can't be overloaded. Equivalents exist as `Files.createTempFile()` and `Files.createTempDirectory()`.
##### `startsWith`, `endsWith`, `normalize`, `resolve`, `resolveSibling`
These exist as member functions on `Path`
##### `relativeTo`, `relativeToOrNull`, `relativeToOrSelf`, `toRelativeString`, `toRelativeStringOrNull`
This functionality exists as the `Path.relativize` member function, which is equivalent to `relativeTo`, but with the receiver and parameter flipped. `foo.relativeTo(bar)` is equivalent to `bar.relativize(foo)`. We could potentially add a `relativizeOrNull` extension to make that pattern simpler.
##### `isRooted`
`Path` has a `root` method, so `isRooted` is equivalent to `root != null`
### New extensions
All of the simple boolean attribute checks from `java.nio.Files` were added as extensions on `Path`. These extensions are used commonly enough that it seems worth supporting them. This functionality for `File` is implemented as member methods.
The following `Path` extensions were added:
- `exists`
- `isDirectory`
- `isExecutable`
- `isFile`
- `isHidden`
- `isReadable`
- `isSameFile`
- `isSymbolicLink`
- `isWritable`
Some of these extensions take options that are forwarded to their `Files` method, so all of the extensions were implemented as functions rather than properties for consistency.
Additionally, `Path.listFiles` was added to match the `File.listFiles` method. One motivation for its addition was that it's used several times in the implementation of other file extensions. The way to list directory contents with `java.nio` is via `Files.newDirectoryStream()`, which returns an iterable object that must be closed to avoid leaking resources. It's difficult to use correctly with functions like `map` and `filter`, so this extension was added as a simpler, less error-prone alternative.
### Other changes
I added overloads of several of the read-write that take `OpenOptions` to expose the greater control that `java.nio` introduces. For example, you can use `printWriter(APPEND)` to create a `PrintWriter` that doesn't delete the contents of an existing file.
All the new extensions throw exceptions (such as `NoSuchFileException`) from `java.nio` rather than the copies from `kotlin.io`. The `kotlin.io` copies take `File` objects as parameters, and so aren't compatible with `Path`s.
### Address review comments
- Move varargs parameters to the last position
- Remove PathTreeWalk
#KT-19192
sebastian.sellmair