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
This leads to cleaner error messages in Gradle variant-aware dependency
resolution failures. Gradle has deprecated those configurations since
long ago, and we didn't see much use of them as variant-aware dependency
resolution entities either.
So this commits sets `canBeConsumed` to false on these configuratons:
* compile (+ testCompile, fooCompile in MPP)
* runtime (+ testRuntime, fooRuntime, ...)
* compileOnly (+ testCompileOnly, fooCompileOnly, ...)
* default (+ fooDefault in MPP)
This change replaces the PR #3995
Mads Ager