in startCoroutineUninterceptedOrReturn. Otherwise, the coroutine will
not be interceptable later.
Add a test, which checks, that intercepted continuation is released.
#KT-55869
Previously, a function reference that used generic parameters from its
outer scope was lowered into a top-level non-generic subclass of
`FunctionN`, with `FunctionN` type arguments referencing type parameters
not present in the scope anymore. This sometimes resulted in generating
malformed mangled names.
From now on the generated subclass of `FunctionN` is generic. The needed
type arguments are passed upon instantiation, when the relevant generic
parameters are present in the scope.
function enter -> default 1 -> default 2 -> rest of function
\----------^ \----------^
This probably has no effect (in non-stupid code, at least), but it makes
graph construction more architecturally correct (now value parameters'
subgraphs get attached to a node).
Interpretation: a graph A is a subgraph of B if information available at
nodes of A depends on the paths taken in B. For example, local classes
are subgraphs of a graph in which they are declared, and members of
those classes are subgraphs of the local class itself - because these
members can reference captured values.
Consequences:
* if graph G is a subgraph of node N, then G is a subgraph of N's
owner;
* `ControlFlowAnalysisDiagnosticComponent` will only visit root graphs;
* `graph.traverse` will ignore subgraph boundaries, as if all subgraphs
are inlined into one huge root graph;
* if a control flow checker needs information from a declaration to
which a graph is attached, it must look at subgraphs explicitly.
For example, consider the `callsInPlace` checker. When a function
has a `callsInPlace` contract and a local declaration, the checker must
visit that local declaration to ensure it does not capture the allegedly
called-in-place argument - hence `graph.traverse` will look at the
nodes. However, the local declaration can also be a function with its
own `callsInPlace` contracts, so the checker should also run for it in
isolation. If that sounds quadratic, that's because unfortunately it is.
useCorrectedNullabilityForTypeParameters = true only might lead
to something becomes a DNN when otherwise it wasn't.
It seems safe to use it here, since if compiler has generated DNN, then
it's OK to assume that it checked necessary conditions, and it's likely
that it had useCorrectedNullabilityForTypeParameters = true as well, there.
Anyway, it looks saner than having an exception here.
Also, we assume here that metadata leading to exception might only be generated
with ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated LF
(at least, we don't have contradicting evidences),
thus it's mostly a preparations in case we decide to enable
ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated in 1.9.
^KT-55357 Fixed
^KT-55388 Related
^KT-36770 Related
Previously, it worked by default because ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated
was enabled by default since 1.8, but we have to disable it because of KT-55357
Turning off the fix by default is not a breaking change per se, because
1.8 has not yet been released.
^KT-55357 Related
^KT-36770 Related
^KT-53041 Open
Ilmir Usmanov