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
Revert "[JS IR] Build hybrid versions of stdlib and kotlin.test"
This reverts commit b9f88350dd.
Revert "[JS IR] Add gradle plugin integration tests"
This reverts commit d872b27663.
Revert "Update bootstrap"
This reverts commit bc47594c7a.
Revert "[JS IR] Support generating both IR and pre-IR libraries"
This reverts commit 1b8df45bfe.
Since KotlinTypeMapper is no longer used in the JVM IR backend, we need
not run CodegenBinding.initTrace and check that names of local entities
are exactly equal to local names computed by that algorithm.
However, it's still useful as an opt-in flag, to discover issues where
unwanted elements take part in the naming (such as temporary IR
variables, see for example cb2e68fece). So we introduce a new command
line argument -Xir-check-local-names which, when the IR backend is used
(via -Xuse-ir), launches the name computation algorithm from the old
backend and then compares that the names are exactly equal to the names
computed by the IR backend in InventNamesForLocalClasses.
Relates to KT-8834, we continue reducing differences between old and new
inference. Note that as for `SamConversionPerArgument`, this feature
is enabled in the compiler and not in the IDE to avoid breaking code
for those users that already enabled new inference in the compiler
If new inference is enabled only for IDE analysis, then this feature
will be disabled to reduce difference between new and old inference,
but if new inference is enabled in the compiler, then this feature
will be enabled too to preserve behavior of new inference for
compilation
#KT-32175 Fixed
#KT-32143 Fixed
#KT-32123 Fixed
#KT-32230 Fixed
`-Xbuild-file` argument allows the compiler to run without
passing any Kotlin source file in arguments.
We have been using this property in
Kotlin Gradle plugin for a few important cases:
1. incremental compilation (to update caches when there are only removed files);
2. for KAPT (Kotlin sources don't make sense in context
of running APs).
We want to stop using `-Xbuild-file` in Kotlin Gradle plugin,
and avoid breaking the Gradle plugin or IC in other build-systems.
This change adds an argument to explicitly run
the compiler without specifying any Kotlin source file.
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
Nikolay Krasko