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
When dependencies are added to our corresponding configurations,
report errors, as there's no proper way to add those dependencies.
Issue #KT-43944 Fixed
When resolving inline class methods in binary dependencies we look for
methods matching both the new and the old mangling scheme. On the IR
backend the method signature has to be computed for the inline class
replacement, since the logic for signature mangling is not contained in
the method signature mapping, unlike in the old backend.
Take local/anonymous classes and their inner classes into account.
Simplify approximation: use first available super classifier instead
of first super class. This approximation should only happen for
private declarations that were not previously approximated by frontend.
So basically the only requirement for the approximated types is to be
denotable. Note that this only works if the types are not used later.
JVM uses a different string table implementatin as it needs exact
types of private members for reflection.
^KT-20996 Fixed
Dynamically calculating a year is problematic, especially in cases like
FIR where generation happens in every build. When you are working on a
last year's commit, each build creates a bunch of uncommited
changes of updating the year in copyrights.
This list is backed by mutable list and during iterating on it
we can resolve supertypes of that class via IDE light classes
as IJ Java resolve may resolve a lot of stuff by fir light classes
This causes ConcurrentModificationException
Before this commit, during the resolve of companion objects we used
the same context than for any nested class. However, during companion
object resolve we should not have companion object receiver itself
accessible in any case (in particular, it should not be accessible
in constructor). So in this commit we introduced separate context
for this purpose.
Igor Yakovlev