Before the fix for KT-7185, the file looked like:
package suppression
@file:Suppress("UnusedImport")
import java.io.* // unused
And it was parsed incorrectly, because @file: annotations
should come before package directive
But after fix, import directives started being parsed that lead
to wrong unused import (because suppression wasn't parsed still)
The case for KT-7237 belongs to /NoGTInTypeArguments test
It was fixed implicitly: before it recovery was working but the name for
the next parameter was attached to type argument list.
After that change, parameter without name gets parsed correctly (with an
error of course)
^KT-13731 Fixed
^KT-7237 Fixed
This fix is work-around fixing incompatibility issue between gradle
tooling api bundled in IDEA and gradle tooling api in gradle 4.x.
When null messages were logged it resulted in the following error:
"java.io.StreamCorruptedException: invalid stream header: ED000573"
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
1. There is no need to specify repositories.
2. We don't use 'org.jetbrains.kotlin:gradle-api:1.6' anymore.
3. kotlin-serialization-unshaded does not need dependencies,
because it does not contain source code (it simply packages jar).
AGP 3.0.x requires explicit 'kapt' dependency on databinding compiler.
Also databinding v2 (enabled by default in AGP 3.2.0) generates different
java classes.
Bridge function should be created when return type of override function
is specialised to unboxed inline class. Thus return type should be used in
function signature.
Non-inline-class return types are not added to signature for interop and
infrastructure reasons ("toString" would become "toString_ret$kotlin_String")
Use signature of function 'target' (a real function that will
be called instad of fake override) to make boxing/unboxing decision for
return value and type parameters on call site.
Vyacheslav Gerasimov