This class should contain 'global' settings for reference shortening;
ATM it only contains the `removeThis` flag
In the future this setting might be merged together with
`ShortenStrategy` to be computed on per-element basis
- Since this documentation was written, the usages of contextual modules
have expanded beyond outsider files, for example to support `KtModule`
disambiguation for library elements. Hence, it was necessary to update
the documentation accordingly.
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
Also, remove setting the value of allowUnstableDependencies to true if
K2 is used because we want K2 to report errors (as K1 does) on
unstable-ABI dependencies.
#KT-61598 Fixed
Currently, PROPERTY_WITH_NO_TYPE_NO_INITIALIZER is reported for local
variables, but not reported for member or top-level properties. Add a
check to the common `checkPropertyInitializer` for when a property
type cannot be determined from the getter.
This also corrects a K1 versus K2 inconsistency, where K2 would allow
blocks from getters to determine property type instead of only allowing
expression bodies.
^KT-59935 Fixed
^KT-60117 Fixed
^KT-60123 Fixed
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
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
- 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
Roman Golyshev