- 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
Previously files were sorted only when IncrementalDataProvider
was not null to normalize js output in case of incremental compilation.
Because of that an output js file could be different after rebuild
in IC tests.
The issue could be reproduced anywhere, but the tests failed only on
Windows, and it seems tests were not run on Windows for some time.
Consider following case:
fun foo(): Unit = run { "hello" }
Previously, NI would analyze lambda body without expected type, because
it is a type variable 'R' from 'run', which hasn't been fixed yet. This
leads to treating "hello" as lambda-return argument and adding bogus
'String' constraint on 'R', and, consequently, type mismatch.
Now, we peek into current constraint system and check if return-type of
lambda is type variable with upper-Unit constraint (which is exactly
condition for its body to be Unit-coerced). If so, then we provide
expected Unit-type for body explicitly, and the rest will be done
automatically (in particular, in aforementioned example "hello" wouldn't
be treated as lambda return argument).
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
Only require implementations to be able to compute the enum class name
and the corresponding entry name. Only this should be necessary to
correctly resolve the argument; the resolvers will find the
corresponding class descriptor if necessary
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
Mikhael Bogdanov