Revert "`KotlinCoreEnvironment`: set `ideaCompatibleBuildNumber = "173.1"`"
This reverts commit d3321cc77a6b55d8b8ff3c3a16473f2f3b378533.
Revert "`JvmFacade`-related tests repair"
This reverts commit faeacdd17d37a4d733b686f3a1d5e8fc6ea54d79.
Revert "Register new service and EPs added in 173"
This reverts commit 5d227c0e714c1b4316e7b8daca1f208ee423f448.
Writing a Jigsaw-modular Kotlin program which doesn't require
kotlin.stdlib doesn't make sense because it most likely will fail at
runtime, on access to anything from the standard library. Previously, we
checked that kotlin.stdlib was in the module graph, but that's not
enough, we should also check that the source module requires it.
'-Xallow-kotlin-package' can be used to disable the error.
Add a test checking that an indirect (transitive) dependency is also OK
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
LightClassGenerationSupport:
Includes utilities related to generating light classes
Primary client of this service are KtLight* implementation classes
KotlinAsJavaSupport:
Provides APIs to transform kotlin code into Psi* entities
Primary client of this service is JavaElementFinder
ReplErrorLogger is not really a class that logs errors, ReplWriter exists for that purpose (I don't think ReplWriter has a good API as well, though). The only thing it does is that is passes exceptions got from the compiler to IDE. So, in my opinion, the old name is rather confusing and it doesn't describe what the class actually do.
Also rethrow exceptions explicitly.
These warnings are technically correct but are too noisy and have little
value in case a user explicitly specifies unstable API version: it's
unlikely that seeing these warnings, the user will choose to rollback to
an earlier API version, since new API is probably one of the reasons
that user specified that unstable version to begin with.
So, in "kotlinc -language-version 1.3 -api-version 1.3 -cp
kotlin-stdlib-1.2.jar", we will no longer report a warning that the
attached stdlib has a version older than explicit API version (so long
as 1.3 remains unstable).
Note that we _could_ have reported these warnings in "kotlinc
-language-version 1.3 -cp kotlin-stdlib-1.2.jar", because in this case
the user might've not even be concerned with the new API in 1.3 and was
only looking for new language features. However, we still think that
it'd be unnecessary and one opt-in to the experimental world (with
LV=1.3 in this case) is enough
#KT-22777 Fixed
API version inference happens in
JvmRuntimeVersionsConsistencyChecker.checkCompilerClasspathConsistency
only in the case when API version is specified explicitly (with
"-api-version ..."). However, if the user specifies "-language-version
1.3", what's likely meant is "-language-version 1.3 -api-version 1.3",
and it would be unwise to infer API version to 1.2 (which is the version
of the attached stdlib) in this case.
Therefore, API version is now considered to be specified explicitly if
_either_ -language-version or -api-version is specified on the command
line
#KT-22777 In Progress
Vyacheslav Gerasimov