There was a bug in the DFS. Whenever we encountered a "requires
transitive X" directive in some module, we recursively invoked DFS not
on X but on `dependencyName`, which is the target module that we're
trying to find the path to. And that always failed, because no module
requires itself.
#KT-66275 Fixed
There's no behavior specific for JVM backend diagnostics in any of the
affected tests, and this code is using an incorrect way to obtain those
diagnostics, so it should be removed anyway.
In 9b5a9ccb `throws Exception` was removed from java test sources and
all checked exceptions were wrapped with `RuntimeException`
But it was forgotten that there is a `rethrow` utility, which doesn't
wrap exception but makes the javac happy at the same time
Originally it was an application-level component, which caused non-trivial
logic and cognitive load to carefully handle those extensions to avoid
memory leaks.
6740a596 introduced a way to easily register `DiagnosticSuppressor` to
project, and this commit continues this work, making it a proper
project-level extension
A lot of changes caused by the fact, that this extension is needed to be
obtained from `BindingContext` (see `BindingContextSuppressCache` and
its usages), so almost all changes are introducing `Project` to
`BindingContext`
^KT-66449 Fixed
Used frontend changed for K2
It turned out test was compiling only one source file (a.kt). Test adjusted, so all three source files(a.kt, b/c.kt, c/d/e.kt) are now compiled into klib, so more usecases are tested
^KT-64452 Fixed
Merge-request: KT-MR-14700
Merged-by: Vladimir Sukharev <Vladimir.Sukharev@jetbrains.com>
All existing tests use custom test data for FIR because the diagnostic
text in FIR has to have a dot at the end. Also, the K2 checker doesn't
check usages in imports because there are no "import checkers" in K2
right now, this will need to be fixed later if necessary.
#KT-60797 Fixed
This is needed to reduce the size of generated test files, which started
to exceed default IDE limit
Also update some (mostly old) test utilities to remove exceptions from
java signatures
Somehow we ended up in the state where we have two diagnostics which are
not covered by any tests in the project. This commit adds simple tests
for them.
#KT-60797
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
Duplicated messages in testdata appeared because default renderer
renders diagnostic spans ambiguously. It shows only start position.
In fact, there are 3 failures, 2 of them distinguish only by the
diagnostic end offset. See youtrack for more information.
The issue about inconvenient rendering is KT-64989.
#KT-64608
Pass the metadata serializer instance instead. This allows to further
reduce code duplication by introducing the common interface
`KlibSingleFileMetadataSerializer` for abstracting away K1 and K2
representation of a source file, as well as reusing
`Fir2KlibMetadataSerializer` across different backends.
KT-64392
- 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
In IR interpreter we have "preprocessors". Preprocessor is a
transformer that changes IR expressions in a way that we can
interpret them at least partially.
We have two places where interpretation is happening:
1. Right after fir2ir where we evaluate only strictly necessary
expression for `const val` and annotations.
2. In lowering for every backend where we are doing some
constant folding.
Earlier, to avoid double work, we didn't launch preprocessors
in backend if we were using K2. But this approach breaks compilation
for MPP projects where one module is compiled with K1 into klib
and the overall project is compiled with K2. On the backend side,
we are mistakenly assuming that preprocessors were launched, but they
were not.
The solution is to run preprocessors only on the backend side. If we
think about it, interpretation on fir2ir doesn't require any
preprocessing because we are working only with expressions that are
correct and must be fully evaluated.
#KT-62126 Fixed
See the comment in the code for more info.
No proper test added because the compiler test infrastructure lacks the
ability to run old compiler versions, however I've verified manually
that the change fixes the issue.
#KT-62531 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
This commit is a slightly modified revert of 4f29c113.
IS_PRE_RELEASE allows to make LATEST_STABLE version behave as
experimental when this flag is set to true.
The general goal is to prepare fix of KT-62058; after this commit
one can do it by changing IS_PRE_RELEASE flag to true.
The fix of KT-62058 is planned to be done during bootstrapping.
This preparation and the future fix are parts of umbrella KT-61951.
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