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
The tests need to be able to parse and render CodeMetaInfo for different
platforms. For example, we must draw a run gutter a MAC application on
OSX, but for a Win application, the gutter should not be drawn at the
same time. This commit allows to do such checks. In order to indicate
on which platform it should be rendered, it is necessary to specify the
platform for a specific CodeMetaInfo in the test data in the format
{OSX,Unix,Win}, if the block with platforms is missing, this means
that it should be rendered on each platform.
<!LINE_MARKER{OSX}(...)!> - should only be on OSX
<!LINE_MARKER(...)!> - should be on any platform
The current test framework has a number of shortcomings, such as
different markups for different kinds, those formats can not be
mixed in one test file, lacks composability, re-use of it is complicated
This commit contains the first version of the new test runner
to which tests will be migrated in the future.
The inline class is boxed when we pass it as lambda argument, now we
unbox it. If the underlying type is not Any or Any?, bridge method does
the unboxing.
#KT-32450 Fixed
#KT-39923 Fixed
#KT-32228 Fixed
#KT-40282 Fixed
The disposable which decrements ourProjectCount was a non-capturing
lambda, meaning it had a single identity and could only be registered
in the Disposer tree once. Therefore the application environment
would never be disposed if ourProjectCount ever went above 1.
This helps to reduce peak memory in lowerings/codegen by a lot.
A more robust approach would be to have a separate BindingContext for
each file, and clear each of them after running psi2ir on it. This would
also lower peak memory usage in psi2ir.
Provide a fallback workaround compiler argument
-Xir-do-not-clear-binding-context just in case BindingContext is in fact
used somewhere and it's not caught by tests.
Compute FQ name of the main class right after running the analysis and
before invoking codegen. This is needed because MainFunctionDetector
depends on BindingContext, and JVM IR needs to clear BindingContext as
soon as it's not necessary to reduce peak memory usage, thus breaking
any usages of data from it after the codegen.
Also refactor and use the extracted, but not properly reused previously,
copy of findMainClass in findMainClass.kt.
Note that this replaces NPE in KT-42868 with an UOE.
This map is populated during psi2ir and is only used in
insertImplicitCasts, after which it makes sense to clear it, otherwise
it strongly references a lot of descriptors for calls in other files
which would never be used.
Move `postprocess` into `generateSingleFile` and do those steps on each
file instead. This will allow to create
`GeneratorContext.callToSubstitutedDescriptorMap` for each file and
clear it after its only call site (InsertImplicitCasts) has used it.
Also simplify code a bit.
AJ