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
It's been used to bring immutability to DelegatingDataFlowInfo
But in case of statements sequence like:
x = 1
...
x = 1
it would lead to huge DelegatingDataFlowInfo where each of
getCollectedNullability call works for O(n) where n is amount
of assignments
The solution is to get rid of reference to parent and to update
relevant maps properly
In next commits immutable maps will be used instead of making copies each
time
Dmitry Savvinov