Prior to this commit code completion for .kts files was supported only
partially. Script has an implicit receiver - base class representing a
script itself, the point where its basic API resides. The knowledge of
this receiver was missing.
There are at least two context where this knowledge is crucial:
1. Code highlighting (worked fine)
2. Code completion (failed)
`FirScriptConfiguratorExtension` is responsible for filling
`FirScriptBuilder` with base script class (in addition to other
properties). See usages of [1] in its implementation.
The thing is that resolution during the completion works a bit
different. Instead of converting the entire `KtFile` it's interested
in `KtScript` only. See usages of [2].
`RawFirBuilder.Visitor.visitScript` is where implicit receivers were
missing.
Code completion and inspections applied to `.kts` files already have
`FirScript` and don't require its full reconstruction with expensive
`FirScriptConfiguratorExtension`. `RawFirBuilder.Visitor` was modified
to support sometimes already existing `FirElement`.
----------------------------------------------------------------
[1]: ScriptCompilationConfiguration.baseClass
[2]: RawFirBuilder.Visitor.convertScript
To be reported with [1] imports require source. It was missing for
implicit script imports.
`FirScriptConfiguratorExtensionImpl` was extended and now adds fake
source elements (users don't see imports in the source code).
Since diagnostics for implicit import statements are meaningless for
IDE, they are suppressed in `LLFirDiagnosticReporter`.
----------------------------------------------------------------------
[1]: DiagnosticReporter.reportOn()
The following two registrars were missing:
- FirScriptingCompilerExtensionIdeRegistrar
- FirScriptingSamWithReceiverExtensionRegistrar
`FirScriptingCompilerExtensionIdeRegistrar` was introduced as a copy of
`FirScriptingCompilerExtensionRegistrar` adapted for usage from IDE.
`FirRegisteredPluginAnnotations` and `FirJvmTypeMapper` are mandatory at
`FirExtensionService.registerExtensions` and reported as missing at
runtime.
Default imports coming from script configuration can be of "star" type.
Prior to this commit they were effectively ignored due to a bug at FQN
assembly.
Before: org.gradle.dsl.* => org.gradle.dsl.
After: org.gradle.dsl.* => org.gradle.dsl
Otherwise, the type parameters of the `kotlin.script.state` property
of type `AggregatedReplStageState` were undefined, which led to
building an ill-formed signature for the script class constructor.
From now on we load script configurations for embedded Kotlin code
snippets. Potentially this might lead to an extra load during a file
analysis.
IDEA side test for the change is here:
`HighlightingTestGenerated.Uncategorized#testKotlinInJavaInjection`
^KT-56632 fixed
Scope for incremental compilation refers to binaries from previous step
of IC. It is used not only in IC context itself, but also it is
subtracted from original libraries scope. Before previous commit there
was such scheme:
1. create incremental compilation context for files of specific session
2. subtract IC scope from main libraries scope
3. use updated libraries scope to create library session
4. create all needed source session(s)
So here was a side effect of creating new IC context, which
1. is smelling code, because it increases mind complexity
2. hard to implement with new session utilities
So to fix this problem this commit changes the scheme above:
1. create IC scope and modify libraries scope
2. create libraries session
3. create source session(s) and IC context for them
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
JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
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
It helps to:
- keep declarations even if they are not reachable and not exported
- not minify names of not exported declarations
Compiler argument: -Xir-keep=A,B
Can be used for top-level declarations or for member
^KT-54118 fixed
Review: https://jetbrains.team/p/kt/reviews/6753
Meaningful semantic change was splitted into 5 commits to simplify the
change review. Sinle commit would be too big.
Why replace source to binary: to get rid of kotlin-reflect in Kotlin
plugin artifact KTIJ-22276
Note: Kotlin Maven artifacts (./gradlew publish) changed their
dependency on kotlin-reflect
Review: https://jetbrains.team/p/kt/reviews/6753
Why: I'm going to replace source dependency on kotlin-reflect with
binary dependency. Normalize reflect dependency before global
processing.
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
#KT-53009 fixed
#KT-42810 should be possible now too, but more testing is needed
#KT-42101 can also be addressed now, but first the serialization
of the imported scripts property should be solved
required for restoring compatibility with IDE REPL usages (scratch
files included), since IDE counterpart needs a reliable signal
when the processing of the REPL snippet/command is completed
Alexander Udalov