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
The purpose of this class was to avoid reporting conflicting JVM
signatures / accidental override errors when there's a similar (e.g.
conflicting overloads) diagnostic already reported.
It was not used meaningfully because it only affected diagnostics
reported by the old JVM backend. Also, in real life, backend diagnostics
would not be reported anyway in most cases because backend is not even
run if there's an error after frontend.
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
After legacy light classes were removed, the only remaining usage was in
KotlinLightClassBuilderFactory where we ran JVM backend in the
LIGHT_CLASSES mode, and that was only used from diagnostic tests to
report JVM backend diagnostics.
We don't actually need to build stubs here, so we can just use ASM's
class writer, which means that StubClassBuilder and all its dependencies
can be removed.
This way it is easier to understand where `notifyAnalysis*`
methods were called. Also, in K1, we are not including
`checkKotlinPackageUsageFor*` in the analysis time.
Invert the logic of IR/FIR2IR-based generators: change the CLI argument
to -Xuse-fir-fake-override-builder, test directive to
USE_FIR_BASED_FAKE_OVERRIDE_GENERATOR, etc.
The changes in test data caused by using IR fake override builder by
default are in the subsequent commit.
#KT-61514
The expected format was Kotlin language version (e.g. `2.0`), however the actual passed values were Kotlin release versions (e.g. `2.0.0`)
^KT-65986 In Progress
[KAPT] KT-65684 Set languageVersion=1.9 in KaptToolIntegrationTestGenerated
[KAPT] KT-65684 Re-enable a few now-passing tests in Kapt4IT
[KAPT] KT-65684 Fix the logic setting -Xuse-kapt4 flag in Kapt4IT.forceKapt4()
The change is needed to make sure that all the tests have the flag set,
otherwise some of them would silently switch to the fallback node.
Also disables a few now failing tests.
[KAPT] KT-65684 Revert "KT-64385 Enable K2 KAPT by default"
This reverts commit 7e9d6e60
Merge-request: KT-MR-14291
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
- 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
These arguments switch language features which cannot be disabled
anymore because they're enabled from some LV not later than 1.4, and the
minimal supported LV is currently 1.4.
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
Alexander Udalov