* Avoid resolving deprecated configurations in tests
This PR enables more integration tests run with warning-mode=fail by
updating "resolveAllConfigurations" task in a way where we don't resolve
deprecated configurations and instead check dependencies on alternative
configurations.
* Add custom resolvable configuration for testing
This leads to clearer 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, ...)
This change replaces the PR #3995
Fixed by outlining JS code that uses Kotlin variables making usages of
these locals explicit and preventing bugs due to one-sided variable renaming.
This prevents using Kotlin variables as lvalue in JS code.
This commit includes a lot of minor changes in testdata: new infrastructure
requires that each test file in one testdata file in one module must
have unique name, but a lot of existing spec tests didn't satisfy
this requirement
Previously CodeMetaInfoParser saved MatchResults for each meta info in
text (and for each meta info it was different string with text because
of extracting parsed part from original text), so it led to O(n^2)
memory complexity (where n is a size of original text).
Such complexity caused OOME in case of big testdata (~1k meta infos
for text of 4k lines)
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
Bingran