This is still not 100% foolproof because one may place such a
requirement manually on a suspend function (with `@RequireKotlin`, for
example), which will trick the compiler into thinking that this is a new
suspend function, even if it was compiled with old coroutines. But it's
still better than only checking the version number
Recently, the container for "lookups" has changed to THashSet
And it lead to exception:
java.io.InvalidClassException: gnu.trove.THashSet;
local class incompatible: stream classdesc
serialVersionUID = -8659895033752433145,
local class serialVersionUID = -1699000958968314003
The reasons for different versions of THashSet are unknown
(though likely related to a slightly different classpathes),
but the fix is rather straight-forward
#KT-26011 Fixed
Can't use `KotlinCodeStyleSettings` instead `KtCodeStyleSettings`,
because current `KotlinCodeStyleSettings` class is already used in third
party plugin.
In this tests there are two variants:
- One extracts the lambda
- And another extracts the whole call
For some reason, the order of completion variants has been changed in 182
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
Comparing files by paths is too error-prone and it created a problem
here, where paths of File instances on Windows use "\" as a separator,
whereas VirtualFile paths always use "/", resulting in empty source
lists being compiled. This issue was introduced in 1582354077. Instead,
get the instance of the VirtualFile by path, and use its identity for
comparison
When sourceMapEmbedSources are not null and source maps is disabled warning is reported, since it has effect only when source maps are enabled. Also this fixes some JPS JS with warnings count assertions.
Now, trivial info is not being perstisted in the maps of DataFlowInfo
At the same time, we don't record trivial DataFlowInfo instances in binding context:
org.jetbrains.kotlin.resolve.bindingContextUtil.BindingContextUtilsKt#recordDataFlowInfo
Namely, it happens in case when expression is a callee expression of
"variable as function" calls (see
org.jetbrains.kotlin.idea.codeInsight.ExpressionTypeTestGenerated#testKt11601)
At the same time, there's a hack in `org.jetbrains.kotlin.resolve.calls.callUtil.CallUtilKt#getType`
that helps to obtain type itself for these callees from the resolved calls.
So, it will work anyway if we use `noTypeInfo` here, that is kind of
correct since there's no non-trivial info anyway
Nicolay Mitropolsky