The hack involving disabling constant inlining via the inlineConstVal
flag was necessary to avoid a JS IR incremental compilation issue.
Since the issue has been fixed, the hack is no longer needed.
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
Marco Pennekamp