Pass it in the CompilerConfiguration instead of LanguageVersionSettings.
This is better because LanguageVersionSettings is accessible everywhere
in front-end and back-end, and this flag should not be used there
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
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
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
The problem was that LanguageVersionSettingsImpl.DEFAULT did not have
"WarnOnCoroutines" as a feature and so it was manually added to the settings,
but only in two places: in the compiler and in the IDE
It should be a valid case to invoke the 1.1 compiler with the 1.0 runtime in
the classpath and "-api-version 1.0". However, previously it was an error and
the message suggested to specify "-language-version 1.0". Language version 1.0
implies API version 1.0, so this effectively made the "-api-version" option
useless
Instead of multiple .kjsm files for different classes and .kotlin_string_table,
.kotlin_file_table, .kotlin_classes files for each package, serialize the
contents of each package to a single foo/bar/baz/baz.kjsm file. The short name
of the file is the last segment in the FQ name of the package, or
"root-package" if the package is root.
There are two main reasons for this change:
1) Such structure takes less space, is more IO-friendly and will not cause
multiple exceptions as the old one, where we sometimes tried to read
non-existing files
2) This is exactly the same format that is used to serialize built-in
declarations (.kotlin_builtins) at the moment, which will allow us to reuse
some code
Also write a separate Header protobuf message to the beginning of the .kjsm
file. This will be used as arguments of the kotlin.Metadata annotation are used
in the JVM-specific parts of the compiler: to be able to provide some general
information about the binary file without parsing the whole protobuf data.
This commit breaks decompiled text & stub builder consistency tests. This is OK
because they're removed in a future commit.
Fixes EA-79605, EA-81947, EA-84277 and maybe EA-86787
#KT-10894 Fixed
#KT-14124 Fixed
#KT-15755 Fixed
This is a way for future compilers to cause previous compilers to report
diagnostics on usages of some declarations. Diagnostic can have a message
(and/or error code), level (error, warning, or completely hide the declaration
from the resolution), and Kotlin version, since which the diagnostic should no
longer be reported
- Introduce new 'rem' operator convention
- Prefer 'rem()' to 'mod()' when both are available, even if mod() is a
member, and rem() -- an extension
- Place operator 'rem' under the language feature
Dmitry Jemerov