Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
There are two visible effects of this change:
1) If an empty argument is passed in quotes, it will be parsed as an
empty string and handled by the compiler, which will report an error
later. The specific error is not very important because it's an edge
case anyway; at the moment, "source file or directory not found:" is
reported which is no better than the "invalid flag:" error reported
by javac in the similar case
2) It's no longer possible to split an argument into several parts and
quote them separately, such as:
"-langu"ag"e-"ver'sio'n 1.2
No test added for this change in behavior since it's an even edgier
case. Note that javac also prohibits this.
#KT-27226 Fixed
Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
Comparing files by paths is too error-prone and it created a problem
here, where paths of File instances on Windows use "\" as a separator,
whereas VirtualFile paths always use "/", resulting in empty source
lists being compiled. This issue was introduced in 1582354077. Instead,
get the instance of the VirtualFile by path, and use its identity for
comparison
When sourceMapEmbedSources are not null and source maps is disabled warning is reported, since it has effect only when source maps are enabled. Also this fixes some JPS JS with warnings count assertions.
Do not call this method the second time in KotlinToJVMBytecodeCompiler
where all KtFile instances are already created; just get only those
files that are in the needed module, which can be determined solely by
the file path.
Also "kotlinize" getKtFiles and rename to createKtFiles
Registration can't be removed because there's still a usage in ClsFileImpl:
Caused by: java.lang.IllegalArgumentException: Missing extension point: com.intellij.psi.clsCustomNavigationPolicy in area null
at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.getExtensionPoint(ExtensionsAreaImpl.java:335)
at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.getExtensionPoint(ExtensionsAreaImpl.java:26)
at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:104)
at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:98)
at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:93)
at com.intellij.psi.impl.compiled.ClsFileImpl.getNavigationElement(ClsFileImpl.java:312)
Alexander Udalov