^KT-55788
Test `parameter_jvmInline.kt` is removed because now members with value
classes are not included in light classes and don't have PSI representation
Initially, it was added accidentally as part of e3f987459c
and missed all out processes.
Adding @SinceKotlin("1.7") after the annotation has already been
published before is not really a problem, because it only may be used
with an experimental `-Xcontext-receivers` flag, thus it doesn't have
to be a part of our regular backward compatibility routine.
^KT-55226 Fixed
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.
Instead, rely on the variable assignment analyzer to properly restrict
smart casts. This makes error messages more consistent, but otherwise
should have no effect.
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.
Apparently if you add an empty line at the start of the FIR file, that's
not enough of a difference for the test suite to complain about, but
enough for it to not add the FIR_IDENTICAL directive...
While it is theoretically useful to know that `{ while(true) {} }`
returns Nothing, CFG node deadness is not precise enough to do that: if
the entire lambda is dead, it's no longer possible to find out whether
the loop is terminating. Besides, `while (true)` and `if (true)` are
pretty much the only constructs like that anyway.
Note that this commit does not affect resolution for lambdas that end in
a Nothing-returning expression, e.g. `throw`.
* `return` should only be added to the last statement if the return
type is not Unit
* If there is a `return` without an argument, then the expected return
type is Unit and the last expression is not a return argument (unless
it's an incomplete call, in which case it is inferred to return Unit;
this behavior is questionable, but inherited from K1)
* There should be a constraint on return arguments even if the expected
type is Unit, otherwise errors will be missed
* When the expected type is known, using the call completion results
writer is pointless (and probably subtly wrong).
^KT-54742 Fixed
The JsAllowValueClassesInExternals feature is enabled explicitly,
because otherwise it's enabled
implicitly depending on the backend. See:
org/jetbrains/kotlin/test/builders/LanguageVersionSettingsBuilder.kt:90
A property may have a fake source return kind, while its accessor
has a real source kind. In this case we can't "just copy"
the property return type down to the accessor.
Dmitriy Novozhilov