1. Don't need to print stack trace on trivial errors such as invalid
CLI argument or incompatible library version.
2. Re-organization of `logWarning()` & `logError()` calls inside
the klib tool.
Since `createStubBasedFirSymbolProviderForClassFiles` works for
builtins (after 866368cf), the provider sometimes has to handle
declarations from builtins (`Any?.toString()` or `arrayOf`, for example)
To provide correct origin for such declarations, we have to compute
the origin on the per-declaration basis instead of always setting
`Library` or `BuiltIn` origin
Providing correct origins should improve the consistency of
deserialized fir declarations
To reduce duplication, `getContainerSource` now also uses
`getDeclarationOriginFor`
If deserialized declarations from built-ins have a container source
which implements `FacadeSource`, it might cause different problems
during IR compilation.
For example, IR lowering of `Any?.toString()` function call was broken
because IR assumed that this declaration belonged to a facade class
"kotlin.kotlin", which does not exist.
We introduce a special kind of container source for the built-ins
declarations, and there are in fact no real facade classes for such
declarations.
Also, `LLFirModuleWithDependenciesSymbolProvider` is modified to
correctly handle such sources. Previously it only handled
`FacadeSource`s, and now it knows about our special source for
built-ins.
^KT-62859 Fixed
This fixes a false positive OUTER_CLASS_ARGUMENTS_REQUIRED when
referring to an inner class of a supertype that is extended using a
typealias.
#KT-62099 Fixed
- This is in line with the API of `FirSymbolNamesProvider`. It only
makes sense to compute package sets for source and library modules.
Also, source module package set computation in the IDE is currently
broken, so it's good to be able to return `null` in the meantime.
- This also allows the removal of the workaround for source modules in
`LLFirProviderHelper`, as the IDE declaration provider can now return
`null` itself in this case.
^KTIJ-27411
- This will allow the Kotlin declaration provider to compute package
sets based on the library module associated with the stub-based symbol
provider.
^KTIJ-27411
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.
Dmitriy Dolovov