Invocation of Logger.fatal() may cause severe side effects such as
throwing an exception or even terminating the current JVM process
(check various implementations of this function for details).
The code that uses Logger.fatal() sometimes expects a particular kind
of side effect. This is totally a design flaw. And it's definitely not
a responsibility of Logger to influence the execution flow of
the program.
While not beeing final solution, this is closer to what
we want to have in the end. Enabling on non-JVM targets
would help better testing.
Enabling in JVM is now not possible yet, as some of the bugs are
not fixed yet (check KT-61360 for details)
^KT-62476
Add cache for reflection lookup of CLI arguments.
Replace CLI argument list with map.
The current cli parser tries to match every possible command line
argument against each command line argument, essentially in a double
loop. This fix replaces one of the loops with a map lookup. Building the
map is not expensive, and pays for itself even with a modest number of
parameters. The map is cached between calls, making subsequent calls
much cheaper. If run in a daemon, repeatedly parsing, e.g., 250
arguments, this speeds up argument parsing by a factor 20.
Disallow -shortName=value in CLI arguments.
Co-authored-by: Troels Lund <troels@google.com>
- This helps to track down disposables which are never disposed, and
reduces confusion when printing disposables in general (the names will
now be meaningful, instead of endless lists of "newDisposable" and
"TestDisposable").
^KT-64099
- The disposable passed to `getOrCreateApplicationEnvironment` should
not actually be the application environment's disposable, which is
created inside the function. Instead, it should be the project's
disposable, which is used to track how many projects still rely on the
shared application environment.
- This issue wasn't apparent before because there is no visible
consequence when an application isn't disposed after all projects have
been disposed (during tests). However, the solution for KT-63650
relies on application environments being disposed after all projects
are disposed, so that a new application environment with a different
configuration can be created. (Only one shared application environment
may be active at the same time.)
^KT-63650
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
Dmitriy Dolovov