Also, require users of K2MetadataCompiler to pass "-Xmulti-platform"
manually. Gradle and Maven plugins already do that, so only users who
invoke kotlinc directly are going to be affected by this
#KT-19287 Fixed
* Support flags with any value (not just Boolean)
* Support all flags by parsing arguments in KotlinFacetSettings, instead
of manually listing known flags
#KT-19210 Fixed
Note that the history file name was changed (.kotlin_history ->
.kotlinc_history) because the history is now stored in a different
(incompatible) format.
#KT-11369 Fixed
Deprecate KotlinScriptDefinition#getDependenciesFor
Expose dependencyResolver as a property
KotlinScriptExternalImportsProvider is the component clients should be asking for dependencies
Before this change jansi was used by the compiler,
unless "kotlin.colors.enabled" is not set to false.
This caused multiple issues in different build systems,
where newer or older version of jansi could crash the JVM
since it uses native code.
The following short term solutions were discussed:
* Set "kotlin.colors.enabled" to false where jansi is not needed
(basically in any build system).
* Set "kotlin.colors.enabled" to true where jansi is needed,
and use it only when the system property is set to true.
Escaped codes are only needed in CLI tools (kotlinc, REPL),
so the second solution is preferred (less places to set the property).
#KT-17031 fixed
#KT-18874 fixed
#KT-18927 fixed
No test added because it would involve running javac 9 and because tests
run JavaBuilder in the same process, this would require either a new
module in our project with dependency on JDK 9 (which would require
everyone to install JDK 9), or complex code that runs javac in another
process
Also report the "named does not read unnamed" error, which was not
possible previously because we wouldn't be able to read anything from
kotlin-stdlib (because it was added to the unnamed module by default)
Essentially, the logic that was previously in
JvmModuleAccessibilityChecker.diagnosticFor, is moved into a new
abstract method JavaModuleResolver.checkAccessibility, which is
implemented differently in the compiler and in the IDE. In the compiler,
we use our JavaModuleInfo and JavaModuleGraph, as previously. In the
IDE, we use intellij's PsiJavaModule and JavaModuleGraphUtil.
This fixes strange behavior in IDE where some modules could be observed
in an invalid state. The cause of that was the JavaModuleGraph instance
caching modules in IdeJavaModuleResolver, which is a project component.
Moreover, this will allow to report an error "named module does not read
unnamed module" in the compiler, and avoid reporting it in the IDE (see
the comment in IdeJavaModuleResolver about that)
No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
Ensure that messages reported on a file but with no line information are
reported before diagnostics related to code. This fixes
Java9ModulesIntegrationTest.testSeveralModulesWithTheSameName on some
machines
These options are no longer needed because the problematic code in
intellij-core that was accessing these private APIs has been dealt with
in the 171 branch.
The remaining options in "Codegen Tests" run configurations are needed
because of reflection usage on JDK internals in KtUsefulTestCase
If a path to the module-info.java file is passed as an argument, we
should treat all other source files passed as arguments (either as
individual source files or inside a source directory) as members of that
module. Previously we treated other source files as members of the
unnamed module, and this resulted in incorrect errors when using a
member exported with a qualification from another named module, for
example
#KT-18598 In Fixed
Mikhail Glukhikh