This argument is useful in situations where the stdlib version which the
code compiles against is different from the one which is available at
runtime, such as the case of kotlin-gradle-plugin, which depends on the
compiler/stdlib compiled by 1.4, but may be executed in Gradle where
only 1.3.x is available.
#KT-37435
The fact that this was a codegen box test was probably an abuse of the
testing infrastructure. It was never meant to pass, since it checks
presence of an error, and diagnostic tests aren't enough since they
might not check the full compiler execution.
Set first supported version to 1.3
Add property for oldest depecated language version in order to control unsupported ones
Report error on attempts to manually disable language feature from unsupported versions
Update test data, drop compatibility tests for features from unsupported versions
KT-36146 In progress
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
#KT-35740 fixed
also add tests and drop logger usage in the cli dependencies manager:
the logger is normally unitialized in the usage scenarios, but related
warnings are annoying.
This option is not widely used and its implementation relies on a
complicated mechanism of a module-wide metadata, which is not properly
supported in the IDE (see IdeModuleAnnotationsResolver).
#KT-34649 Fixed
Motivation: missing visibility modifier is an error in visibility modifiers list, so we should highlight this list.
Including a name in the range is convenient for using alt+enter (you don't have to move cursor from name to fun/class/val keyword)
Also change NO_EXPLICIT_RETURN_TYPE_IN_API_MODE diagnostic range to 'declaration name' to match corresponding IDE inspection.
Fix stylistic problems and typos after review
Change CLI flag to -Xexplicit-api=strict|warning. 'Disable' state and 'mode' suffix are left out as implementation details.
Change intention title to 'make X public explicitly'
Do not report 'no explicit visibility' on property accessors
Set DECLARATION_SIGNATURE as a range for report
Rename internal diagnostic from _MIGRATION to _WARNING
simon.ogorodnik