Before this fix line numbers for function call arguments were not generated,
so if argument was on another line than function call it was
impossible to stop on argument line during debugging.
Now line number for each argument is generated if necessary
(another line than function call line).
#KT-17144 Fixed
This is mostly a revert of e5a128ab, 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
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)
The main reason of this change is that major changes are required in how
command line arguments are parsed in kotlinc, and it's much easier to
make them in our own codebase (given that the code is short and simple
enough) than in a third-party library
Instead of reusing the same AnalyzerFacade that is used for resolution
of a module to resolve its dependencies, analyze each dependency
module/library with a facade depending on its target platform. Introduce
and use CommonLibraryDetectionUtil in addition to
KotlinJavaScriptLibraryDetectionUtil, to detect common libraries (with
.kotlin_metadata files).
Note that before multi-platform projects, this was not needed because
there were only two platforms (JVM and JS), and JVM module had only JVM
modules/libraries as dependencies, JS module had only JS
modules/libraries as dependencies. Now, for example, a JVM module can
have a common module/library as a dependency, and it would be incorrect
to analyze that dependency with JvmAnalyzerFacade because that facade
does not know anything about .kotlin_metadata files.
The changes in Dsl.kt and KotlinCacheServiceImpl.kt are needed because
PsiElement.getJavaDescriptorResolver, called from some IDE code, started
to fail on a common module, because the container for a common module
does not have the JavaDescriptorResolver
Recently the CompilerMessageLocation.NO_LOCATION was replaced with a null value.
This caused daemon clients to report "Unexpected message" for compiler messages without location.
Mikhail Zarechenskiy