The inheritance is still needed because of the code in intellij-core,
specifically in JavaCoreProjectEnvironment.addSourcesToClasspath and
CoreJavaDirectoryService.getPackage, which assumes that the
JavaFileManager instance in the project is a CoreJavaFileManager
findClass(String, GlobalSearchScope) is invoked for example when we're
resolving supertypes of classes in Java libraries. Previously, it never
found nested classes and falled back to CoreJavaFileManager's
implementation, which lacks a fix for the original issue (KT-12664,
which was fixed in JvmDependenciesIndex in 5a533a52 and 164c72e8)
#KT-16931 Fixed
Split KotlinPsiElementFinderImpl into two classes: one is used in the
compiler (boolean field isCliFileManager previously handled that), the
other is used in IDE and possibly other non-CLI scenarios.
Also avoid a possible class cast exception in
KotlinJavaPsiFacade.knownClassNamesInPackage
See 8466270 for the reason.
Note that actually we do not report errors on such cases because psiElement is not valid, but in tests for intentions we check all errors
Fix CCE on callable references to Java methods.
Fix qualification of callable references without receivers.
Fix processing of calls/callable references to object extensions
and extension members.
Do not explicate short companion references
#KT-16809 Fixed
'tools_jar_profile' Maven profile is activated only if 'kotlin-annotation-processing-maven-build.txt' exists.
It already works this say for the 'kotlin-annotation-processing' artifact.
Relates to KT-15562 "Service is dying".
This commit includes multiple changes:
1. JPS & Gradle daemon clients are refactored to use `connectAndLease` from `KotlinCompilerClient`.
`connectAndLease` was introduced in previous commits
2. `withKotlin` was removed because `connectAndLease` already covers retrying on connection error
3. Gradle flag files creation is changed:
* client-alive flag file lives as long as Gradle instance lives,
* session-alive flag file lives until the end of a build.
Before this change a daemon client debug messages were printed
only when the client could not connect and the 'kotlin.daemon.verbose'
system property was set up.
Now messages are printed if the debug logging is enabled and
the 'kotlin.daemon.verbose' is set up.
#KT-16917 fixed
The daemon code contained the following code:
```
ManagementFactory.getRuntimeMXBean().name
```
As it turns out `RuntimeImpl#getName` calls `VMManagementImpl#getVmId`,
which in turn calls `InetAddress.getLocalHost().getHostName()`.
`InetAddress.getLocalHost()` tries to resolve by making a DNS-request.
In case of a DNS-problem or a network misconfiguration,
resolving localhost can be very slow,
so a daemon client can disconnect
by the timeout (10 seconds) and fallback to the non-daemon compilation.
This change removes the call `getRuntimeMXBean().name`
(it is only used for logs).
The RMI documentation (http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/javarmiproperties.html)
says it is useful to set up a `java.rmi.server.hostname`
system property on a client and a server.
When the property is set up on a client, I saw that "RenewClean" threads
stopped listening to my external IP, so all client and server threads
are now only listening the loopback interface.
I also changed the way the property is set up on the server side:
before the change it was passed in jvmargs at a process launcher.
I moved this code directly to the main method of the daemon,
because it is easy to forget to set up the property,
when running the main for debug purposes.
It takes time to find compile errors or exceptions,
when a Gradle test build fails, because a debug log
is very verbose.
This change prints all error messages from Gradle
when a test build fails unexpectedly.
Pavel V. Talanov