Also minor cleanup. Remove the comment about the issue jansi#35 because
although the issue is fixed, the behavior is correct right now: we
enable colors by default iff stderr is a TTY (and the platform is not
Windows), and to determine that we need to call `CLibrary.isatty`.
#KT-55784
add the hack to project environment creation, instead of compliation
call sites, covers missing scenarions with maven scripting and K@ now
and should help to avoid problems in the future.
#KT-54461 fixed
Now the plugin-related compiler arguments are respected then used in
the compiler configuration (only in the static part, not supported
if set in a refinement callback)
Note that the "embeddable" version of the plugin should be used if
embeddable compiler is used.
#KT-54095 fixed
- Move out getAnalyzerServices from FirFrontendFacade to TestSetupUtils
- Simplify DependencyListForCliModule. Now it takes BinaryModuleData as input
- FirOutArtifact contains several FirOutputArtifactPart
- Simplify FirFrontendFacade
- Setup JDK default module roots in `StandaloneProjectFactory` (compare
with `KotlinCoreEnvironment`). The implementation is a distilled
version of `ClasspathRootsResolver`'s default module handling.
- This fixes an issue where some LL FIR tests with JDK 17 and 11 had
mismatched types between Kotlin and Java sources.
^KT-55566 fixed
Do not recompute children on each file request
At the same time, we should clear the roots after each compilation
just the same way as we do for common jars
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
- add FastJarFS cache cleaning to the daemon implementation, so
the behavior is now the same as for CoreJarFS
- clear not only mappings but also handlers cache: this may result some
slowdown on comparison with the previous cleaning implementation,
but should avoid unreliable behavior on heavy parallel build usages.
FastJarFS was behaving differently than the regular CoreJarFS it
tries to replace, namely it was cleaned after each compilation
(had the lifetime tied to core env).
This commit preserve it in the app env the same way as CoreJarFS,
so it could be reused in parallel builds and preserved if automatic
cleanup of the app env is turned off,
But since FastJarFS caches also mmf handles, the additional handles
cleaning is introduced that triggers after all possibly parallel
compilations are finished.
The latter is used e.g. for scripts in source roots handling
as implemented in the commit
"Scripting: update scripts in source roots handling"
The former implementation did not covered all the cases.
#KT-54355 fixed
Disposer uses passed object identity to decide should it be registered
Since lambda, that passed into disposer doesn't capture anything, it has
only one instance, so it ends up being registered only once
While it should be registered for every parentDisposable
getOrCreateApplicationEnvironment is main entrypoint to create
ApplicationEnvironment in production and compiler tests
It is subject to be called concurrently, that's why
APPLICATION_LOCK exists
ApplicationEnvironment itself hosts Application from idea-core
It is actually singleton, that is subject to be disposed, once all
operations referencing it completes
To properly dispose ApplicationEnvironment when there is no references
left, we maintain reference counter aka ourProjectCount
Originally, there was data-race caused by the fact, that ourProjectCount
was updated after publication of application
Linear, data-race occurs in following order
T1: getOrCreateApplicationEnvironment returns application
T2: Disposes its reference to application, causing ourProjectCount to
reach zero, and disposing application that is already available to T1
T1: Updates counter, but its application already disposed
Roman Efremov