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>
is called. Some kotlin plugins (for example JS) re-use
DefaultKotlinSourceSet class for their source sets. However
DefaultKotlinSourceSet has an API that is connected to IDE import
particularly `getDependenciesTransformation`. Since Kotlin/JS doesn't
support metadata dependencies, and their transformations as well
we should lift strong requirement for compileDependenciesTransformation
to be set for each source set. Instead, just return empty list of
transformations.
^KT-55347 Verification Pending
Pure JS projects should still be able to import even thus calling
`getDependenciesTransformation` should not throw any runtime exceptions
and results should be empty. Since JS projects doesn't support metadata
dependencies transformations.
^KT-55347 In Progress
of the class used in @UseSerializers: Use methods to receive
full list of supertypes.
K1 supertypes() call returned all supertypes, while
IrClass.supertypes and FirClassSymbol.resolvedSuperTypes return only immediate ones.
This lead to a difference in behavior between K1 and K2, and regression
after plugin backend was rewritten from descriptors to IR.
#KT-55340 Fixed
as ISE is more appropriate exception for validation.
Improve SerializerClassLowering.runPluginSafe so precise IrClass
where plugin have failed can be reported for non-fatal errors.
#KT-55296 Fixed
Makes executor be able to find and download necessary runtimes and
create device with appropriate runtime available. Replaces device names
with identifiers
Co-authored-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Merge-request: KT-MR-7919
Merged-by: Pavel Punegov <Pavel.Punegov@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
Dmitriy Novozhilov