Fixed the incremental compilation issue,
which had prevented enabling const inlining during constant
evaluation and folding a constant expression with JS code.
^KT-62425
The diagnostics cannot be implemented with the FIR frontend checker
because it requires constant evaluation over FIR.
Therefore, the diagnostics are implemented as a set of klib checks over IR.
For the diagnostics, the js() call argument must be
evaluated and inlined as IrConst<String> into IR
in the same way as const val initializers and annotation arguments.
^KT-59388 Fixed
^KT-59399 Fixed
^KT-62425 Fixed
The meaning of this check is the same as K1
JSCODE_ARGUMENT_SHOULD_BE_CONSTANT and JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostics.
The main difference is that K2 JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostic checks the js() argument in the same way as
const val initializers or annotation arguments are checked.
This means that, the K2 diagnostic is stricter than original
K1 JSCODE_ARGUMENT_SHOULD_BE_CONSTANT diagnostic,
which allows the use of non-constant vals.
^KT-59435 Fixed
Added JSCODE_ARGUMENT_NON_CONST_EXPRESSION warning which
checks non constant variable usages in js() argument expressions.
The fix is related to KT-57156.
This class enables printing the import list in generated files
in a smarter way.
Also, refactor `Importable` interface hierarchy, namely, don't inherit
`TypeRef` from `Importable`, since we have types like `TypeRef.Star`
which are not really importable.
Replace the `Importable#typeWithArguments` property with
the `TypeRef#render` method to utilize `ImportCollector` while rendering
types.
As of now, this implementation is not supposed to be used at all
If (for some reason) it becomes relevant again, please refer
to the 7fd441f1 commit which contained a FE10 implementation
of this service (copied from the old FE10 implementation of
import optimizer)
We don't plan to seriously support the FE10 implementation of
`KtImportsOptimizer` service, since it's not going to be used in IDE
(it has its own old version of import optimization logic)
`KtImportOptimizerResult.unusedImports` should be removed soon, and
part of the testdata for the import optimizer service should go
to `intellij` repository
Previously, kapt skipped the execution, if the "kapt" configuration had
no direct dependencies (via `kapt.dependencies.isEmpty()`).
This lead to kapt not working, if all
annotation processors are declared in a super-configuration of kapt.
With this change, we also consider super-configurations
(via `kapt.allDependencies.isEmpty`) and fix the described bug.
^KT-62518 Fixed
- This is more consistent with "top-level callable names in package" and
simplifies the set construction quite a bit, as we can avoid a lot of
`asString` conversions.
- `LLFirProviderHelper` is guarded by `allowKotlinPackage` and the
symbol names provider should reflect that in the name sets.
- Note that this does not apply to stub-based deserialized symbol
providers, because they do not pass any value to `allowKotlinPackage`.
^KT-57314
`project.extraProperties` may contain values that are not `String`s. To
avoid failing on those values, we should cast the value with
`as? String` instead of `as String?`.
Test: New PropertiesBuildServiceTest
^KT-62496 Fixed
Alexander Korepanov