Before this commit, we used type after smart cast both for original
FirThisReceiverExpression and for wrapping FirExpressionWithSmartCast.
However, this makes FIR2IR implicit cast generator work incorrectly
(it decides not to insert implicit cast because original type is the same).
After this commit, expressions have different types and implicit cast
generator works properly.
This is a hack to work around the fact that type mappings should not be
inherited by inlining contexts for lambdas called from anonymous
objects. As the lambda can call the inline function again, this could
produce a reference to the original object, which is remapped to a new
type in the parent context. Unfortunately, there are many redundant
`MethodRemapper`s between the lambda and the class file, so simply
editing `TypeRemapper` does not work. Hence, this hack. For now.
(Issue found by compiling IntelliJ IDEA BTW.)
After adding extension invoke on DeepRecursiveFunction in 1.4,
the compiler start reporting another error and now it doesn't write
info about callable descriptor. Therefore it's needed to use another
source of info for expression type
^KT-40926 Fixed
Do not report same set of diagnostics for variable call if actual
error was happened with a function candidate. Here the candidate is
invoke function on DeepRecursiveFunction
^KT-40991 Fixed
^KT-41491 Fixed
^KT-40926 In Progress
This is needed for cases when test pipeline assumes that some part of
pipeline may be unavailable because of errors on previous stage.
For example, this may occur in some test which check something on IR
but contains backend facade for compiling binary dependencies. In
this case testdata with frontend errors is allowed if test has only
one module which should not be compiled
Rules of directives resolving:
- If no `MODULE` or `FILE` was declared in test then all directives
belongs to module
- If `FILE` is declared, then all directives after it will belong to
file until next `FILE` or `MODULE` directive will be declared
- All directives between `MODULE` and `FILE` directives belongs to module
- All directives before first `MODULE` are global and belongs to each
declared module
Type of a block is a kind of irrelevant for lambdas: their type is much
more complicated and defined via FirDataFlowAnalyzer#returnExpressionsOfAnonymousFunction
at at FirCallCompleter.LambdaAnalyzerImpl#analyzeAndGetLambdaReturnArguments
It might be necessary for cases like
run @l1{
run {
if (...) return@l1 1
}
}
"if" is a synthetic call, but without candidate since there's just one branch
But return@l1 1 is incomplete because it's resolved in dependent context
and "1" is hang incomplete integer literal
Victor Petukhov