Add some classes to hierarchy of `ESValue`:
- `ESReceiver` -- representation of receiver
of lambda function
- `ESDataFlow` and `ESDataFlowReceiver` -- little refactoring of entities
that holds information for DFA (description in comments in code).
Also add kdoc to classes of `ESValue` hierarchy
Consider following expression: 'call() is Foo'. Suppose that we know
something about the 'call()', e.g. 'returns(foo) -> <condition>'
Previously, we've tried to re-use knowledge about 'call()', constructing
some smart clause, like 'returns(true) -> foo is Foo && <condition>'.
The conceptual error here is that *we can't* argue that <condition>
holds. Imagine that 'call()' actually has unspecified 'returns(foo2) ->
<!condition>', and 'foo2 is Foo' also holds. Then we would get
'returns(true) -> foo2 is Foo && <condition>' <=> 'returns(true) ->
<condition>' for the whole call, which is not correct.
More concrete example would be something like:
'if (!x.isNullOrEmpty() is Boolean)'
^KT-27241 Fixed
It is safe to treat DefaultValueArgument as UNKNOWN_COMPUTATION, because
default arguments can't break smartcasts.
Possibly, they can add new ones, but it can be supported later.
^KT-25278 Fixed
The order of types enumeration has been changed recently:
previously it was collected at first from a child and then from
its parent, but now it's being collected in order of appearance
- 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).
This commits introduces testdata changes, where NI behaviour strictly
improved, after several previous fixes.
For some tests, just WITH_NEW_INFERENCE directive was added. It
indicates, that some of previous commits first introduced error in that
test, and then some other commit fixed it (netting no overall testdata
change). It is preferrably to keep those annotations until we will
migrate to NI completely, to prevent unexpected regressions.
- 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
Dmitriy Novozhilov