In this commit we build self importing scope from scratch.
Using member scope provider is probably incorrect because of possible changes.
At any invalidation we should rebuild it.
In this commit, we build FirFile from the beginning if in-block modifications are detected.
However, better way would be to rebuild only part of FirFile in this case
Before this commit, we read/wrote 'enabled' directly from PropertiesComponent.
Now we do only initial reading and then store modified value in field.
This should make 'enabled' reading faster.
It looks like VFS_CHANGES subscription ignores project boundaries so all events are processed by every listener. If event has a hard reference to project in the requestor field, it might leak through the collection of pending events.
An attempt to fix holding test projects through pending events.
#KT-33802 Fixed
In COMPOSITE analysis we don't have a constant SDK dependency for whole
ResolutionFacade, so we have to find it manually via calling
'findSdkAcrossDependencies'
In SEPARATE mode we do have such a constant SDK dependency, but there
was an assumption that it doesn't make a difference (i.e.
findSdkAcrossDependencies always return the same SDK as passed constant
one)
Turns out that assumption was wrong, particularly for projects with
duplicate SDK entries in project structure. Then we would choose one SDK
in some cases, and the other one on other cases - even though they a
bit-to-bit equal, we will create separate descriptors for them, which
might lead to some issues, like in KT-34802
^KT-34802 Fixed
This commit add feature for disabling searching for data class ComponentN method and destruction declarations that could encrease usages search.
See KT-23278
## 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
'Kotlin keyword' rule configured as fallback rule for all Kotlin keywords:
- Created 'var'/'val' rules with fallback to 'Kotlin keyword'
- BUILTIN_ANNOTATION rule fallback changed from Java to 'Kotlin keyword'
#KT-13344 Fixed
Use Gradle Project IDs instead of names, because for composite Gradle
builds module names are appended with some additional prefixes, which
causes mismatch
Mikhail Glukhikh