This commit restores the heuristic removed in 9df02b2366, but only
enables it in case the class wasn't found with the name mapped initially
according to the InnerClasses attribute values. This helps to support
class files which do not have the InnerClasses attribute for all nested
referenced classes, such as those generated by Groovy.
Note that in theory it's still possible for this code to behave
incorrectly, for example a reference to a class `C` nested in a
_top-level_ class named `A$B` will not be loaded by this code correctly.
This is a lower-priority issue and it will need to be fixed later.
#KT-27874 Fixed
The only place where a name with dots was passed to
ClassifierResolutionContext.mapInternalNameToClassId was in
BinaryClassSignatureParser.parseParameterizedClassRefSignature, where
for some reason names can be both of internal (`a/b$c`) and canonical
(`a/b.c`) form. Supporting both names in mapInternalNameToClassId was
confusing because JVM internal names cannot contain dots. Replace dots
with dollars in parseParameterizedClassRefSignature to get rid of the
dot-name handling in mapInternalNameToClassId and rely on the correct
(simplified) InnerClasses-based name resolution later instead.
Also inline mapDescToClassId to its only usage.
Return type is not needed for checking overloads, but querying it may
involve resolving function bodies, which usually happens after overload
checking (see LazyTopDownAnalyzer.analyzeDeclarations) and at this point
can lead to incorrect BACKING_FIELD_REQUIRED value being computed for
some properties (see KT-27895)
#KT-27895 Fixed
Before this commit, kotlin-stdlib-common or -jdk8 can be accidentally
detected as kotlin-stdlib with the following strange version resolve.
Now we check for dash after name, so it's not possible.
This test was originally written with fix for KT-22379
Lately, fix was proven to be wrong and reverted (KT-27084), which made
this test fail.
Correct solution here would be to mute test with link to YT issue, but
unfortunately we don't have infrastructure to mute tests locally (yet),
which is a major issue because this tests is a part of very popular for
local smoke-testing test suite (DiagnosticTestsGenerated).
When there is severe memory load SLRUCache inside getResolutionFacade
may cause double computation of ResolutionFacade, thus will cause
moduleDescriptor to be recreated, and it will be different from one
that is stored in declarationDescriptor
Newer resolutionFacade will actually not built for old moduleDescriptor
and will cause exception
#KT-24788 fixed
Toshiaki Kameyama