For example, a lambda `{ param -> captured }` of type `E.(T) -> U` will
be transformed by LocalDeclarationsLowering into a private static method
fun f$lambda-0($this: E, $captured: U, param: T) = $captured
The reason for such an ordering is that a lambda looks the same as a
local function, and local function can have default arguments, and those
arguments can reference captured variables; thus, captured variables
must come before actual declared arguments.
However, this is not the order that the inliner wants. Moreover, since
it was written to handle lambdas represented as `invoke` methods of
anonymous objects, it does not expect the actual callable method to have
any parameters corresponding to captured variables at all. This results
in it attempting to generate a temporary node with descriptor
(LE;LU;LT;LU;)LU;
while still using locals 1 and 2 as `param` and `$captured` respectively.
In the example above, this is not critical, as they both have reference
type and the lambda will eventually be pasted into a different node
anyway; however, if it happens that one of them is a primitive, or both
are primitives of different types, the bytecode will use incorrect
instructions, causing verification errors. The correct descriptor is
(LE;LT;LU;)LU;
Necessary to support importing file classes annotated @JvmPackageName,
since the actual package fragment they are a part of has the name from
the `package` declaration.
We have plans to extract separate implementation for Gradle scripts, but it
would be better to support something at this point.
For now, we have custom listener, loader and up-to-date check for default configuration manager:
- listener will do forced reload on editor activation, even it is already up-to-date
this is required for Gradle scripts, since it's classpath may depend on other files (`.properties` for example)
- loader will force save failures before running loader. also it will skip loading if
`kotlin.gradle.scripts.useIdeaProjectImport` registry key is enabled
- loader will return inputs with overridden up-to-date checks: file will be considered
out-of-date only when `buildscript` or `plugins` blocks are changed
## Simplify ScriptConfigurationManager mental model
Everything related to cache managing moved to `org.jetbrains.kotlin.idea.core.script.configuration`.
DefaultScriptConfigurationManager slitted into:
- `AbstractScriptConfigurationManager`
- `DefaultScriptConfigurationManager`
- `ScriptClassRootsCache`
The main idea is to simplify the mental model of ScriptConfigurationManager.
Concrete implementation should provide just two things:
- `createCache(): ScriptConfigurationCache` that should return cache implementation with `get` and `set` methods
- `reloadOutOfDateConfiguration(...)` will be called on [cache] miss or when [file] is changed.
Implementation should initiate loading of [file]'s script configuration and call [saveChangedConfiguration]
immediately or in some future (e.g. after user will click "apply context" or/and configuration will be
calculated by some background thread).
Everything around it is implemented in `AbstractScriptConfigurationManager`.
`ScriptClassRootsCache` is extracted from `DefaultScriptConfigurationManager`:
this simplifies `AbstractScriptConfigurationManager`
Also it simplifies ScriptClassRootsCache reset: we can just drop old `ScriptClassRootsCache`
and create new one instead of resetting all internals of `ScriptClassRootsCache`.
Please see KDoc of these classes for more details:
- AbstractScriptConfigurationManager
- DefaultScriptConfigurationManager
- ScriptClassRootsCache
## Cache and up-to-date checks
Writer should put related inputs snapshot for loaded configuration.
This allows reader make up-to-date check for existed entry to avoid starting loading
process for same inputs.
Cache entry may be marked out-of-date.
Also it can be marked up-to-date, but it means that we have up-to-date loaded configuration,
ScriptConfigurationSnapshot.configuration will still contain old applied configuration.
todo: make it more clear by splitting cache entry into loaded and applied configuration with
it's own inputs.
## Loaders
Previously both sync and background loaders may be started for same files - this was useful, but not
required anymore and at the same time greatly complicates the model. So, it was dropped
and now exactly one loader should work for given file (first applicable loader will be called).
Also `ScriptConfigurationLoadingContext` is introduced to limit access to the `ScriptConfigurationManager`
internals.
## Listeners and updating configuration
This things is introduces:
- `ScriptChangesNotifier`
- `ScriptChangeListener`
- `ScriptConfigurationUpdater`
`ScriptChangesNotifier` will call first applicable `ScriptChangeListener` when editor is activated or document changed.
(it treated as applicable if [editorActivated] or [documentChanged] will return true).
Listener may call [ScriptConfigurationUpdater] to invalidate configuration and schedule reloading.
Plugins may override default listening logic by adding it's oven `ScriptChangeListener`.
`ScriptConfigurationUpdater` was extracted from `ScriptConfigurationManagerImpl`.
## Fixed issues and implement persistent FS cache
- Script configuration was not reloaded if query for same file already in progress or ready but not yet applied
- Don't start async loaders for outsider files
- Unused imports: don't start loading script configuration if the result will be not applied automatically
- Fix cases when virtual file can be null
See `DefaultScriptConfigurationManager.reloadOutOfDateConfiguration` KDoc for more details on
dealing with concurrent operations.
## Background executor and progress indicator
This things changed and fixed:
- progress displayed not only when we have more then 3 loading tasks, but also
after 1sec of loading (including case with 1 loading task for example)
- current file is displayed under the progress bar
- progress indication added: it works similar to indexing indicator. When
progress bar is displayed, max is fixed. When all work done for this max,
progress will be started from zero and new max is fixed, and so on
- cancel will drop all loading operation, not just current
- concurrency issues fixed: EA-5244265 and other related to switching between silent and
under progress worker
See `BackgroundExecutor` for more details.
## Gradle specific behavior
We have plans to extract separate implementation for Gradle scripts, but it
would be better to support something at this point.
For now, we have custom listener, loader and up-to-date check for default configuration manager:
- listener will do forced reload on editor activation, even it is already up-to-date
this is required for Gradle scripts, since it's classpath may depend on other files (`.properties` for example)
- loader will force save fails before running loader. also it will skip loading if
`kotlin.gradle.scripts.useIdeaProjectImport` registry key is enabled
- loader will return inputs with overridden up-to-date checks: file will be considered
out-of-date only when `buildscript` or `plugins` blocks are changed
Create a separate _ir.txt bytecode listing file for JVM IR, to avoid
duplicate tests and to fix "Codegent tests on different JDKs"
configuration where this test is muted but passes because only execution
is checked there, not bytecode listing.
Mikhail Glukhikh