Depending on the execution, some accesses to lock could cause NPE.
The best solution we've found so far is to make lock volatile, so that
reads between lock and value are consistent between threads.
It requires further work to determine if we can have one volatile field.
When the other thread has already computed the value and cleared the
lock, the other thread could still enter the computeValueWithoutLock()
and see lock == null
LLFirSessionProvider stores all transitive module dependencies,
even if they are not needed or already invalidated and garbage collected
Now, the dependencies are stored on the weak references, and so then nobody uses them, they will be garbage collected
Kotlin annotations can be called without named parameters even if their
names are different from `value`. So there's no need to search for the
property named "value", since there might be none
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
This is a temporary hack to avoid compiler crashes in some code that
uses builder inference, conditional early returns from lambdas, and
expected types in a certain way. It is not correct - dropping data flow
edges never is - but it is much easier to implement for now than a
proper fix.
The distinction is similar to persistent data structures and their
builders. Only the MutableFlow can be passed to LogicSystem for
modification; when it's ready, it can be converted into PersistentFlow
and attached to a CFG node.
The result is that the API is cleaner, the implementation is a bit more
neat, and hopefully the use of PersistentHashMap.Builder improves
performance a little. Also the node-to-flow map can now be removed in
favor of just storing PersistentFlow inside a node, seeing as it's
explicitly immutable and all that.
Artem Vasilev