Also, remove kotlin-reflect form container module.
Main goal is get rid of kotlin-reflect.jar from modules what required for minimal compiler.jar which can compile Kotlin only to JS to make it smaller.
Original commit: 05c3e7e81d
This is mostly a revert of f936dea8, where the issue of the compiler
failing on repeated command line arguments was worked around. Now the
compiler behaves more properly: it uses the last passed argument and its
value, and prints a warning that several values have been passed. With
this behavior, the workaround is no longer necessary
Original commit: dc5e51f4ac
Use a single coroutinesState instead. Change the coroutines state in
some tests from "warn" to "enable"/"error" to test that deserialization
of older config files works ("warn" is the default value, so it wasn't
testing anything here)
Original commit: be54e4b93b
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 ff783f1f and 2c344635)
#KT-16931 Fixed
Original commit: c67eb84369
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.
Original commit: 9d95c841a6
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.
Original commit: 9819de1abd
Allow the compiler to read such libraries without any errors, at the
risk of crashing with an exception.
Also fix a minor bug in the diagnostic message in LibrarySourcesConfig
and in the corresponding test in KotlinJpsBuildTest
Original commit: bf90cb5cc0
Sharing these settings for reading/writing
between different module during JPS build
may lead to compiler settings
(plugionOptions, in particular) of several
modules to be mixed
#KT-16888 Fixed
Original commit: 505a6bcbf2
Favor language/api version specified in <versionInfo> element
in case it differs from the one in
<option name="_commonCompilerArguments">
#KT-16861 Fixed
Original commit: 2bb7bdfc3f
Previously there were three LanguageFeature instances -- Coroutines,
DoNotWarnOnCoroutines and ErrorOnCoroutines -- which were handled very
awkwardly in the compiler and in the IDE to basically support a language
feature with a more complex state: not just enabled/disabled, but also
enabled with warning and enabled with error. Introduce a new enum
LanguageFeature.State for this and allow LanguageVersionSettings to get
the state of any language feature with 'getFeatureSupport'.
One noticeable drawback of this approach is that looking at the API, one
may assume that any language feature can be in one of the four states
(enabled, warning, error, disabled). This is not true however; there's
only one language feature at the moment (coroutines) for which these
intermediate states (warning, error) are handled in any way. This may be
refactored further by abstracting the logic that checks the language
feature availability so that it would work exactly the same for any
feature.
Another issue is that the difference among ENABLED_WITH_ERROR and
DISABLED is not clear. They are left as separate states because at the
moment, different diagnostics are reported in these two cases and
quick-fixes in IDE rely on that
Original commit: 32826c1686
This makes it possible to avoid the CompilerConfiguration instance in
injectors, because CompilerDeserializationConfiguration was the only
left component that required it.
LanguageVersionSettings is not a good name for this entity anymore, it
should be renamed in the future
Original commit: ac530ac49c
Previously JvmTarget was declared in module 'util' which is accessible
for example from 'frontend', which is not very good.
Also add a superinterface named TargetPlatformVersion which is going to
be used in platform-independent injectors in 'frontend' in the following
commits. Use it in one place (LanguageVersionSettingsProviderImpl.kt)
instead of DescriptionAware because TargetPlatformVersion sounds like a
better abstraction than DescriptionAware here
Original commit: 573c6ab5d4
This would allow building the project with Kotlin JPS plugin on TeamCity where older library takes precendence due to appearing earlier in JPS classpath
Original commit: 73b879ea89
Alexey Tsvetkov