The reason of this change is to make messages (especially warnings)
that are reported by the KLIB resolver become visible to the end user.
This can be achieved to forwarding such messages to the appropriate
compiler's components such as
`org.jetbrains.kotlin.cli.common.messages.MessageCollector` and
`org.jetbrains.kotlin.ir.util.IrMessageLogger`.
Also: The default `DummyLogger` should be used as minimal as possible.
Because it just forwards messages to the standard output (console)
where they can remain unattended. When the compiler is executed
from the Gradle plugin such messages appear only in DEBUG Gradle's log.
^KT-63573
The problem here is that for common session we register `FirJavaElementFinder`
which provides light classes based on expect classes. And then
at the start of analysis of jvm module we register one another
`FirJavaElementFinder`, which sees actual classes and uses them to
build light classes
But, because class ids of expect and actual class pair are the same and
element finders are ordered by creation order, when java resolve tries
to resolve some class, it founds light class based on expect class,
even if we are already in platform session
To fix this problem, it was decided to unregister all previous element
finders on creation of each new session, so old finders won't interfere
with analysis
^KT-63612 Fixed
^KT-64296
The -Xcoverage feature has not worked and has been disabled for a while.
This fix removes it, and all of its uses.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-821
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
- Support WASI mode in CLI and test infrastructure
- Add external declaration checker
- Split Fir diagnostic lists into Base, JS and WASI
#KT-56849 Fixed
Fir2Ir conversion consists of multiple steps with complex logic (like
conversion of each module, actualization, plugins application, constant
evaluation), and to ensure that they all are executed correctly it's
convenient to have the single entry point for all this machinery
- We cannot configure the application's write action accessibility on a
per-test basis because (1) the application may be shared across
concurrent tests and (2) the application is usually cached, so the
configuration will be missed entirely.
- There is actually a much easier solution to allow write access
selectively: We can enable it in `runWriteAction` blocks, and keep it
in a thread local to support concurrent test runs. As Analysis API
tests never call `runWriteAction`, there will be no "analyze cannot be
called from a write action" error, and if `analyze` is somehow called
from a write action, it will now be caught.
^KT-63560 fixed
- In general, Analysis API tests forbid write access because the
Analysis API should not be used from write actions. However, in some
cases we might want tests to e.g. modify PSI, which requires write
access. This change allows `AnalysisApiTestConfigurator`s to enable
write access for the specific test.
When using the compiler with `-Xuse-fast-jar-file-system` enabled, the compiler causes memory leak in ZipImplementation class at MappedByteBuffer.contentsToByteArray method since the Inflater used to deflate zip/jar files, isn't released/ended after the task.
Deduplicate Fir2IrExtensions creation and move the
convertToIrAndActualizeForJvm function to 'cli', which allows to remove
the dependency of 'fir.entrypoint' on 'backend.jvm'.
Note that behavior slightly changes in IncrementalFirJvmCompilerRunner:
previously the value of linkViaSignatures was always false, now it is
taken from the compiler configuration, which seems more correct.
Also, remove setting the value of allowUnstableDependencies to true if
K2 is used because we want K2 to report errors (as K1 does) on
unstable-ABI dependencies.
#KT-61598 Fixed
There are two BUG_FIX features that have
been added to the compiler, without a clear
decision to enable them somewhere in the
future. Since there is no decision to
force users rewrite their code, such
features should not be enabled in
Progressive Mode.
^KT-62644 Fixed
^KT-62143 Fixed
Implement an infrastructure for checking IR before JS klib serialization.
Implement the EXPORTING_JS_NAME_CLASH and EXPORTING_JS_NAME_CLASH_ES checks.
^KT-61710 Fixed
With this change a new `-Xmetadata-klib` CLI flag becomes the
preferable way to instruct K2MetadataCompiler to produce metadata
KLIBs. The old `-Xexpect-actual-linker` flag still works for
K2MetadataCompiler, but that would last just for a short transition
period until the necessary changes are made in the Gradle plugin.
The K2NativeCompiler does not work anymore with `-Xexpect-actual-linker`
and respects only the `-Xmetadata-klib` flag. This is not an
issue since the Gradle plugin anyway supplies both flags for Native
metadata compilations.
^KT-61136
This is a precondition for obsoleting and finally removing
`-Xexpect-actual-linker` CLI key, which became useless since
the removal of ExpectActualTable.
^KT-61136
The checker also checks the metadata version, which
would be handled separately. Now it would never
emmit this error for klib-based backends.
^KT-61773
^KT-61596
^KT-55809
Rename analysis flag `expectActualLinker` to `skipExpectedActualDeclarationChecker`
to better reflect its semantics. This flag isn't used on IDE plugin side, so no
additional changes in `intellij` repo are needed.
^KT-61136
Dmitriy Dolovov