Ignore classes (and references to such classes in declaration signatures) if one of the containing classes has the same simple name. This is forbidden in Java, thus should not be present in kapt source stubs.
Use the bundled compiler plugins for Maven projects (as we do for Gradle projects already) because the plugin provided as a dependency in the POM file may have an incompatible version.
After update of the project to JDK 8, the default JDK at java.home is
now JDK 8. However, this test relied on the fact that the default is JDK
6. Pass the path to the JDK 6 explicitly
Previously, type substitution, which is critical for matching generic
header/impl members with each other, was only performed when
checkImplementationHasHeaderDeclaration was called for impl class
(areCompatibleClassifiers creates the correct substitutor). This was
done in areCompatibleClassifiers: a substitutor which maps type
parameters of the header class to type parameters of the impl class was
created.
Now we create the same substitutor when
checkImplementationHasHeaderDeclaration is called for an impl member of
an impl class as well, manually.
#KT-15230 Fixed
Similarly to getFirstClassifierDiscriminateHeaders, we select the first
non-header class if possible, otherwise we select just the first class.
This makes sure that a reference will never be resolved to a header
class if the corresponding impl class is present.
Note that overall the issue may not be fixed yet, because there are
other scopes where header classes are not yet discriminated
(LazyImportScope, DeserializedMemberScope). However, at this point I
cannot reproduce this problem with these other scopes
#KT-15521 Fixed
Compile the platform-specific code two times: once with the common file
first and the platform file second, and once with the platform file
first and the common file second in the compilation arguments. This is
needed because some issues in the compiler are only reproducible in one
of these two scenarios
Currently this is achieved with several hacks:
- Postpone computation of argument type info when there is no candidate resolver. We have to do this, because we don't have expected type and therefore we could write wrong information to trace
- Presume that for annotation calls there is only one candidate resolver and then resolve arguments with expected type (see `getArgumentTypeInfo`), otherwise because of quadratic complexity of the algorithm resolve would be slow
Avoid temporary file rename if the current name doesn't conflict
with other files in the target directory.
Improve protection against exceptions during the refactoring
which may prevent final rename
Alexander Udalov