If we want to analyse some function's call, we need to know about its
contracts, otherwise resolving the following code would be broken.
Computing return type of function is a prerequisite to using it in any
sensible way, so it's the best place to resolve it to CONTRACTS
KT-50733
- 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).
- Make AbstractDiagnosticsTest dump function contracts
- Add diagnostics tests on parsing contracts
- Add diagnostics tests on smartcats in presence of functions with
contracts
- Add diagnostics tests on initialization and flow in presence of
in-place called lambdas
==========
Introduction of EffectSystem: 16/18
Roman Golyshev