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
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.
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 Petrov