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
The reason is that these configuration problems may be the reason of
compilation errors, but they were hidden from the output because warnings are
not reported when there's at least one error
Original commit: e9a737b85a
This is a severity for mandatory warnings, i.e. those which should be reported
in any case, even if there are compilation errors
Original commit: 7ac96163ac
- Move flag files from the temp dir, because right now JPS cleans temp dir on each build start. Should fix KT-15707, also may affect KT-15562.
- change compiler runner to allow the fix above
- Fix flag file name filtering
- Fix ifAlive handling on the new compile method in the daemon.
Original commit: 7c0cdf90cf
Otherwise it breaks JPS assumptions, that leads to exceptions like:
Error:Kotlin: [Internal Error] java.lang.AssertionError: Couldn't load KotlinClass from /Users/jetbrains/IdeaProjects/KotlinPlaygroundBeta11/out/production/KotlinPlaygroundBeta11/Counter$both$1.class; it may happen because class doesn't have valid Kotlin annotations
at org.jetbrains.kotlin.build.GeneratedJvmClass.<init>(generatedFiles.kt:36)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.getGeneratedFiles(KotlinBuilder.kt:469)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.doBuild(KotlinBuilder.kt:241)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.build(KotlinBuilder.kt:140)
...
Original commit: 9f217de10b
This is a temporary fix, and it should be reverted when "Use project settings" will be disabled by default in modules imported from external build tools (Maven, Gradle).
Original commit: 1fb90ac0fd
Alexey Sedunov