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
Enable custom allocator with -Xallocator=custom.
If the gc is cms (default):
* a patched version of the memory manager is used that does not build a
list of allocated objects.
* a patched version of the cms is used that defers to the allocator for
sweeping.
Otherwise, a warning is printed, and the allocator is used using the
standard api.
Design doc:
https://docs.google.com/document/d/15xMp-nE-DWL8OrtOc8DoXB80AHUphFICEGjj5K0aNFc
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-546
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
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.
This removes the need for hacks around the order in which function
call arguments are visited, fixes called-in-place lambda arguments
for augmented assignment operators, and makes CFG dumps a bit prettier.
I.e. maintain a set of seen lambdas where each marked as either "data
flow only" or "both data and control flow". The latter are truly
parallel with the function being analyzed, while the former have
technically already terminated, we just don't know the types inside them
because they may not have been analyzed yet.
The delegate is resolved in context-dependent mode and thus can be an
incomplete call; if there is no `provideDelegate` method to complete it,
the result is effectively `val x$delegate = y.id()` where `id` is
`fun <T> id(x: T) = x`, except we don't get a real node for `id` so the
DFA edges from lambdas in `y` go who knows where.
Quick quiz:
Q: In a CFG, what does `a -> b -> c -> d` mean?
A: `a`, then `b`, then `c`, then `d`.
Q: In a CFG, what does `a -> b -> d; a -> c -> d` mean?
A: `a`, then `b` or `c`, then `d`.
Q: So how do you encode "a, then (b, then c) or (c, then b), then d`?
A: You can't.
Problem is, you need to, because that's what `a; run2({ b }, { c }); d`
does when `run2` has a contract that it calls both its lambda arguments
in-place: `shuffle(listOf(block1, block2)).forEach { it() }` is a
perfectly valid implementation for it, as little sense as that makes.
So that's what union nodes solve. When a node implements
`UnionNodeMarker`, its inputs are interpreted as "all visited in some
order" instead of the normal "one of the inputs is visited".
Currently this is used for data flow. It *should* also be used for
control flow, but it isn't. But it should be. But that's not so easy.
BTW, `try` exit is NOT a union node; although lambdas in one branch can
be completed according to types' of lambdas in another, data does not
flow between the branches anyway (since we don't know how much of the
`try` executed before jumping into `catch`, and `catch`es are mutually
exclusive) so a `try` expression is more like `when` than a function
call with called-in-place-exactly-once arguments. The fact that
`exitTryExpression` used `processUnionOfArguments` in a weird way
should've hinted at that, but now we know for certain.
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.
If a certain type statement is true on loop entry and all continue
paths, then it is also true on exit if the condition did not reassign
the variable.
^KT-7676 tag fixed-in-k2
It's also not a backwards jump in do-while, unless it's in the loop's
condition, which is a stupid "feature" IMO. As you can probably tell
from the comments added in this commit.
Because in kapt stub generation mode (aka ClassBuilderMode.KAPT3, aka
generateBodies=false in psi2ir), method bodies are not generated and
compiler plugins such as kotlinx-serialization might not expect that.
#KT-54245 Fixed
In some cases where the Kotlin compiler encounters an exception, it attempts to print the contents of the file that it was compiling at the time. Sometimes the content contains symbols that aren't bound to implementations. When that happens the safe value parameters for a function are empty because none of them can be resolved, but the value parameter count is still non-zero because the function reference still has multiple params — this causes exception messages to fail with an error:
```
Exception in thread "main" java.lang.IllegalStateException: Problem with constructing exception message
```
This fixes the issue by only attempting to access the safe value parameters if the list is of the proper size.
KT-54012
Dmitriy Novozhilov