MissingDependencyClassChecker.collectDiagnostics now show only unique diagnostics
As per-file analyzer trace used in checker delegates to resolve session trace, diagnostics might be duplicated because of race condition:
1. If a non-checker thread performs analyze first, diagnostics for global elements will be stored in the resolve session trace only once.
2 If the checker threads comes to the analyze first, diagnostics will be stored in the local trace, and after that might be duplicated in the resolve session trace by other analyzers.
#KT-35578 Fixed
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
Nikolay Krasko