- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
Before this change `filesScope` was effectively empty in cases when
module info is a library, thus looking
into PackageIndexUtil.packageExists(name, indexedFilesScope, project)
was kind of redundant since it always returns false for empty scopes
The initial motivation was run by 1716720604
that made PackageIndexUtil::packageExists calls much more frequent
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
Using the argument value, which is of type "Any?", is more implicit and
thus difficult to read than using the ConstantValue instance and casting
it to the needed constant value implementation before taking the value
Remove KotlinBuiltIns and take a ModuleDescriptor instance in getType
instead. This will allow to create constant values in contexts where
there's no module or built-ins accessible (such as, deserialization of
module annotations during indexing of .kotlin_module files in IDE).
Note that some values (KClassValue, EnumValue, AnnotationValue) still
take module-dependent objects (KotlinType, ClassDescriptor and
AnnotationDescriptor respectively). This is to be refactored later
This commit introduces proper handling of recursion in scopes, which
could occur when some of companion object supertypes are members of
that companion owner:
```
class Container {
open class Base
companion object : Base()
}
```
To resolve `Base`, we have to build member scope for `Container`.
In the member scope of `Container`, we see all classifiers from
companion and his supertypes
So, we have to resolve companion objects supertype, which happens to be
`Base` again - therefore, we encounter recursion here.
Previously, we created `ThrowingLexicalScope` for such recursive calls,
but didn't checked for loop explicitly, which lead to a wide variety of
bugs (see https://jetbrains.quip.com/dc5aABhZoaQY and KT-10532).
To report such cyclic declarations properly, we first change
`ThrowingLexicalScope` to `ErrorLexicalScope` -- the main difference is
that latter doesn't throws ISE when someone tries to resolve type in it,
allowing us to report error instead of crashing with exception.
Then, we add additional fake edge in supertypes graph (from
host-class to companion object) which allows us to piggyback on existing
supertypes loops detection mechanism, and report such cycles for user.
In Gradle, JavaPsiFacade finds Kotlin compiled files as KtFile instances
and tries to obtain classes from them.
And while it returns an empty array anyway, it starts building
unnecessary stub when calling `isScript`
Prior to this change, it was rather slow since it would lead
to a ModuleDescriptor::packageFragmentProviderForWholeModuleWithDependencies
computation, that would force the computation of libraries'
dependencies, that actually was the major bottleneck here.
The idea is that we do not need to search through dependencies
of dependencies, but only need contents of one of the modules
direct content.
This commit is made under the assumption that if a module has may see
some runtime parts, than runtime jar should be among its direct
depenencies.
Effectively it leads to all stubs being built for any once used package
The idea is that they only were used for FILE_TO_PACKAGE_FRAGMENT
that is mostly read in backend and rarely in the IDE, so we can replace
its usages with searching through related package-fragments
Use words 'returnArgument' instead of 'resultArgument' when talking
about values, which can be possibly returned from lambda.
Correct 'addSubsystemForArgument' -> 'addSubsystemFromArgument'
Previously, there was receiver of type Nothing, which could case result
of the call to be inferred to Nothing too. This could case bogus
UNREACHABLE_CODE diagnostics in cases like this:
```
fun <T> id(x: T) = x
fun test() {
id(unresolvedReference) // type of statement is 'Nothing'
// ... everything here is marked as unreachable ...
}
```
This commit changes type of receiver for such calls form Nothing to
ErrorType.
Dmitry Savvinov