A few messages were improved:
* If the daemon process died at the startup, add its last 10 lines of the output to the log and report to the EXCEPTION (ERROR in the case of Gradle) level
* If some exception occurs during connection attempt, add its stacktrace and report to the EXCEPTION (ERROR in the case of Gradle) level
* Added more DEBUG level messages
* Some important messages are moved to the INFO level
* Added a suggestion to report issue to kotl.in/issue
^KT-55322 Fixed
Before this change, the logic was to find the most suitable daemon and try connecting to it in a loop, ignoring the fact that it could be dying. Now, instead of trying to connect to the daemon dying daemon in a loop, we will make only 1 attemp and then skip if it's already dying.
^KT-55322 In Progress
When incremental compilation fails, we currently log it at the `debug`
level (and fall back to non-incremental compilation). This commit will
change it to `warning` so that we can get more user reports, which will
allow us to fix the root cause.
Also make sure the warning includes a stack trace.
Additionally, let ReportSeverity.fromCode() return a non-null value
or throw an exception otherwise as that case is not expected.
^KT-52839 In Progress
Simplify API of InlineConstTracker
In ConstLowering: Move transformer logic to another class to avoid mutable state. Avoid marking all files in module as module. Support of inner classes.
#KT-46506 Fixed
Now compiler flags with boolean values which are controlled by system
properties could be set in similar way. The following syntax is
appropriate. For setting flag:
'-DflagName,'-DflagName=[y|Y|true|TRUE|yes|YES|on|ON]'
for unsetting flag:
'-DflagName=[n|N|false|FALSE|no|NO|off|OFF]'
This change will allow to start Kotlin daemon instances using different
from the current user JDK version and use it to compile Kotlin files.
Old behaviour, when java executable path is not set, is still working
and still,by default, using current user JDK version.
For example, user for some reason wants to use JDK 1.8 as active one,
but compile current project using JDK 16.
Main goal is to support Gradle toolchains.
^KT-45611 In Progress
Otherwise Kotlin cannot be used in Gradle since
https://github.com/openjdk/jdk/commit/ed4c4ee7 where JDK internals
started to be encapsulated by default.
For some reason, using
listOf("--add-opens", "java.base/java.util=ALL-UNNAMED")
doesn't help, so use the more general `--illegal-access=permit`.
#KT-43704
On windows using a project's root
as a working directory for the daemon
seems to prevent removing the directory
when the daemon runs.
Different projects may share an instance of the daemon,
so the issue will be present only in a project
which started the daemon.
Alexander.Likhachev