If only regular kotlin .kt (and .java) files are compiled, do not
register file extensions that may come from discovered script
definitions. Since the discovery is lazy by itself, this should
skip jars processing for regular compilation scenarios without scripts.
#KT-47816 fixed
- process command line properly when plugin is autoloaded
- add and fix options to disable definitions autoloading and discovery
- cleanup unused code
(partial test is added to "avoid definitions discovery" commit)
if the existing list in the FRIENDS_PATH config property created with
Arrays.asList, it contains non-extendable list, and attempt to use
addAll on it leads to an exception.
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
along with source lines mapping, allows to "emulate" usage of the
PSI files which allows to extract source file and line mapping info
on every stage from source element.
It makes sense to use this mapping for the error reporting too.
^KT-51627 Fixed
kotlinc will currently read /tmp/build.txt in an attempt to
determine an IDEA version number for IDEA plugin compatibility
checking. If that file exists and does not match the expected
format kotlinc will fail.
Since standalone kotlinc is not IDEA, this change explicitly
sets the system property for the build number to a fallback
value. That avoids reading /tmp/build.txt.
closes https://github.com/JetBrains/kotlin/pull/4763
because the intention of that configuration is to use "slower" class
reading.
In the near future, even though FIR is enabled, which uses experimental
faster jar file system, FIR clients (e.g., FIR UAST or Android Lint) may
still need to use slower class reading. So, we need to handle that
configuration before checking others.
There are two ways how content roots are registered in compiler configuration
in JVM CLI compiler:
1. Directly from arguments
2. From Module, which build from arguments
And there was a problem that both ways used at the same time in some
circumstances (regular compilation without .xml module file) which
caused duplication of all content roots.
Ideal solution for this problem is removal of Module usages at all,
because it looks like redundant abstraction which just complicate
things, but it's too scary to remove it, because it hove some none
trivial usages inside compiler. So to fix problem with duplicated
roots this commit just removes registration of roots from arguments
if Module is used
ExperimentalUsageChecker.checkCompilerArguments() will crash if there was an error running analyze().
This checks for the error first so it can be properly reported.
Jinseong Jeon