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.
- Huge refactoring for IC
- Update hash combination logic
- Introduce value class for IC hashes
- Calc md5 directly by function IR
- Split IC logic by classes
- Move JsIrLinkerLoader into separate file
- CacheUpdateStatus is a sealed class
- Render TYPE_PARAMETER reified flag
^KT-51081 Fixed
^KT-51084 Fixed
Intellij API Compatibility Check reports that compatibility was broken
for IJ Bazel plugin. This commit fixes this problem.
Binary compatibility was broken in
705a2881fab109ab7d3e365255d01e0491b17d6d.
Ideally, I'd rename extension functions to names other than "frozen" and
"unfrozen" because this would allow keeping source compatibility for
Java clients as well. But the new extension functions API has been
already released in EAP versions of IDEA, and I don't want change the
API back and forth for clients that already migrated to the new API. I
wish I knew earlier that this API is used by external plugins
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.
Victor Petukhov