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
- Add the tests mute system for the diagnostic tests
- Move the code for the test info parsing to the separate package `parsers`
- Unification of the `linked` and `not linked` spec tests
- Package structure is refactored
- Change the multiline comment format with a test information
- Actualize `PrintSpecTestsStatistic`
- Other different code improvements
- Contracts in getter/setter (unexpected behaviour)
- Check smartcasts when non-null assertion for a contract function is used
- Check work of contracts when type parameter of the callsInPlace is specify explicitly
- Check smartcasts working if type checking for contract function is used
victor.petukhov