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
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
Previously, there was a contract that if it contains some
non-trivial type info it also has it in `completeNullabilityInfo`.
But after two previous changes it became false
Previously, it's been working because was almost always
a different instance.
After, the latter change with avoidance of storing trivial
info there, newDataFlowInfo may accidentally become empty
as context.dataFlowInfo.
But we, obviously, should compare it with newContext.dataFlowInfo instead
It may be useful because data-flow info is mostly the same for
neighbouring expressions and changes between them should be minor.
Thus, it should help to avoid making copies of huge maps and reusing
them instead
Alexander Udalov