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.
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.
There's a separate test data directory `testsWithJvmBackend` with a
runner that properly invokes the JVM backend and reports diagnostics
from it. All tests where JVM diagnostic presence/absence is important
were copied/moved there in this and previous commits.
The problem with the code removed in this commit is that it invoked some
parts of the _old JVM backend_ and old light classes, which is very far
from what users see in the production compiler at this point. This led
to real issues where we implemented incorrect behavior in K2 based on
the misleading diagnostic report from the K1 test.
The diagnostic in `triangleWithFlexibleTypeAndSubstitution4.kt` was
removed, but there's a copy of this test in `codegen/box/javaInterop`
which fails for K2 (KT-66529).
The diagnostic in `intersectionWithMappedSignature.kt` was removed and
that is OK because at this point CONFLICTING_JVM_DECLARATIONS there
seems like a bug in the old JVM backend.
In fact the latest compiler (neither K1 nor K2) does NOT report an error
here, see KT-66522. The error was there in the diagnostic test because
the test used custom code which invoked parts of the old JVM backend to
report signature clash errors.
The issue is rather minor and is present since 1.5, so to reduce
confusion, the test is deleted.
#KT-66522
In this commit, tests where backend diagnostics were reported correctly
are being moved.
FirScopeDumpHandler was added to FIR diagnostic tests with JVM backend
to support `SCOPE_DUMP` in `overridesBuiltinNoMagic.kt` and
`charAtAndOverload.kt`.
This is basically a copy of the test
`diagnostics/tests/j+k/primitiveOverrides/triangleWithFlexibleTypeAndSubstitution4.kt`.
The diagnostic version of the test is not removed because it has
frontend-specific diagnostics `FIR_DUMP` and `SCOPE_DUMP`.
This test is copied to make it clear that it actually passes in K1, and
new errors in K2 here are technically a breaking change, see KT-66529.
The error CONFLICTING_INHERITED_JVM_DECLARATIONS was present there only
because diagnostic tests used parts of the old JVM backend to report JVM
backend diagnostics.
#KT-66529
- `typeParameterWithTwoBounds.kt` is already present in
`diagnostics/testsWithJvmBackend/duplicateJvmSignature/erasure/`.
- `clashWithCompanionObjectField.kt` is already present in
`codegen/box/fieldRename/jvmFieldNoClash1.kt`.
- `jvmFieldAndJavaGetter.kt` is already present in
`codegen/box/jvmField/noClashWithInheritedJavaMethod.kt`.
In case of two latter tests on JvmField, there's (correctly) no error
reported in JVM IR, which is why those are box tests.
In most affected tests, the backend diagnostic such as "conflicting JVM
signature" or "accidental override" is directly caused by some already
existing error reported by frontend, so it doesn't make sense to check
backend diagnostics there.
Tests where that was not the case were moved/copied to
`testsWithJvmBackend`.
All of these tests were actually copied to `testsWithJvmBackend` in
866f188120, but it's unclear why they were copied instead of moved. The
test runner for `testsWithJvmBackend` correctly runs the compiler
pipeline and obtains errors reported by the backend, as opposed to the
common diagnostic tests which have a very custom code, using parts of
the old JVM backend, to obtain these diagnostics.
- `require.kt` was added to check JVM accidental override diagnostic
when using the "traits with required classes" feature, which was
removed a long time ago.
- `withErrorTypes.kt` was testing conflicting JVM declarations error (a
backend diagnostic) in presence of error types -- not very useful
scenario because the backend is not run when there's a frontend error.
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.
Annotation arguments cannot contain declarations, so we can use empty
SymbolRemapper instead of DeepCopySymbolRemapper because the latter
introduces some overhead.
#KT-66281
Rename it to `deepCopyWithoutPatchingParents`, move to
`org.jetbrains.kotlin.ir.util`, make it inline+reified, and extract the
common implementation with `deepCopyWithSymbols` into `deepCopyImpl`.
At this point, `deepCopyWithVariables` is the same as
`deepCopyWithSymbols` except that the former doesn't call
`patchDeclarationParents`, which most likely produces incorrect IR in
some call sites.
It was only used to keep track of mappings from old type/value
parameters to new. We can do it manually instead of inheriting from
DeepCopySymbolRemapper, because the latter does more work than needed,
namely it creates 16 hash maps, and traverses the IR tree looking for
any other declarations.
#KT-66281
`hasEqualFqName` is called from `hasAnnotation`, which takes more than
1% of total backend time, so it's important to avoid doing extra work
here.
It seems to be a quirk of the JS IR backend specifically that
`JsExport.Ignore` has incorrect IR parent structure here; for all other
backends, checking FQ name by traversing IR parents should work fine.
#KT-66281
`AbstractTypeChecker.isCommonDenotableType` calls a few functions which
check if the type is flexible, which is not cheap in case of JVM IR, see
`asFlexibleType`.
#KT-66281
There were several problems with it:
1) `isMoreSpecific` should return true if a == b. Otherwise
`isMoreSpecificThenAllOf` would never return true because it's always
invoked with a collection that contains the candidate. K1 behaves
similarly, `OverridingUtil.isMoreSpecific` returns true if a == b.
So in fact, "more" should be understood as "not less" here.
2) `transitivelyMostSpecificMember` in `selectMostSpecificMember` was
always equal to the first element, so `isMoreSpecific` was invoked
with incorrect arguments.
3) At the end of `selectMostSpecificMember`, we selected the first
candidate with the non-flexible return type, however only dynamic
type was considered. We need to check `isFlexible` via type system
instead.
#KT-66120 Fixed
Most of them are passed at all call sites anyway. Having default values
makes it easy to forget to pass some meaningful argument (especially
`LanguageVersionSettingsImpl.DEFAULT` seems scary), and complicates
refactoring.
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
Code fragment is a class that extends from Any, so technically it can
have fake overrides for equals/hashCode/toString. However, K1 does not
build them, and it's already checked in IR text tests in
`analysis/analysis-api/testData/components/compilerFacility/compilation/codeFragments`,
so don't build them in K2 as well. Also, the code in
`KtFirCompilerFacility.createJvmIrCodegenFactory` looks for a single
function defined in the code fragment.
This change fixes FIR tests with JVM IR serialization enabled, some of
which start to fail after enabling IR fake override builder mode by
default.
In this case, even accessing the function body with `IrFunction.body`
does not work in some cases because it tries to load IR and ends up with
unbound symbols for some reason (most likely related to KT-63509). So we
avoid accessing the body by copying the `IrFunction.acceptChildren`
implementation and removing the `body.accept` call.
Using deep-copy to create a fake override is questionable here, but it
will need to be refactored separately.
This is an addition to d4278250e6. Apparently we still need to produce
a new fake override for each inherited static member, because otherwise
we would try to determine the most specific return type, maximum
visibility, etc, all of which makes no sense for static members.
#KT-66152 Fixed
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
Fix some unresolved supertypes. This is necessary to be able to enable
IR fake override builder by default (KT-61514), because it traverses all
supertypes and asserts that they're classes, so that it can build fake
overrides for declarations from there. Without this change, for example
`IrFakeOverrideBuilder.buildFakeOverridesForClass` would crash.
These tests now only make sense for JVM_IR. Incidentally this fixes the
JVM illegal access warnings from generateTests, because the test
framework no longer tries to instantiate these tests (which leads to
`doOpenInternalPackagesIfRequired`) to determine the target backend.
The change in JvmEnvironmentConfigurator is needed so that JVM tests
without target backend would default to JVM IR instead of the old
backend.
Also rename files to match the class names.
This is needed because in case a static member is inherited via a Kotlin
class (class C in the newly added test), its origin becomes
FAKE_OVERRIDE which is technically not Java anymore. After this change,
we'll build fake overrides for static members from superclasses
regardless of whether they come from Java or Kotlin.
Also, move the previous logic of
isOverridableFunction/isOverridableProperty to the only call site at
IdSignatureFactory.
#KT-65589 Fixed
There's no issue or tests because it doesn't affect user-visible
behavior. The only effect of this change is that after IR fake override
builder is enabled by default (KT-61360), tests in
`compiler/testData/ir/sourceRanges` will now pass because using class
start/end is the current behavior in K2 and test data checks it.
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
Otherwise it leads to the following problem in the newly added test.
Suppose that we have a fake override `remove(Int)` inherited from
LinkedList _without_ EnhancedNullability on its parameter type. By
normal Kotlin rules, this method should override the method from
KotlinInterface. However, on JVM we have another overridability check in
IrJavaIncompatibilityRulesOverridabilityCondition which ensures that
"JVM primitivity" of parameter types is the same for the base and the
overridden method.
So the fake override `remove(Int)` from LinkedList is determined to be
override-incompatible with `remove(Int)` from KotlinInterface. But when
we try to create symbols for all fake overrides in the class, we get a
clash because there are two fake overrides with exactly the same
IdSignature, neither of which overrides the other.
If we keep the EnhancedNullability annotation on the parameter, it
starts working because the logic of computing signature in
JvmIrMangler.JvmIrManglerComputer.mangleTypePlatformSpecific adds an
"{EnhancedNullability}" mark to the IdSignature of a fake override from
LinkedList.
#KT-65499 Fixed
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.
This is kind of another fix for KT-65456, independent from the one in
the previous commit. Here we restore the old behavior of
`buildFakeOverridesForClassUsingOverriddenSymbols`, which is used in
places where fake overrides for static declarations from
superclasses are not necessary at all, such as SAM adapters or
annotation implementation classes.
This reverts commit 6271f5cbe5.
The original commit 15094eb03a was reverted because it caused a problem
during bootstrap. That problem is fixed in a subsequent commit.
To add the file name to the exception message similarly to how it's done
in `PerformByIrFilePhase.invokeSequential`, so that exceptions such as
KT-65277 would be easier to diagnose.
In the future version of JavaIncompatibilityRulesOverridabilityCondition
for IR, we need to compute the original JVM signature of a declaration.
In descriptors, it's possible simply by using `original`.
For some reason, codegen box test was not added in 082c337faa. The main
point of it now is to check that everything works correctly in the
IrFakeOverrideBuilder mode.
It affects the `is IrGetField` check in
TypeOperatorLowering.computeNotNullAssertionText, which leads to missing
NPE messages when accessing backing fields of public properties.
#KT-64615
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
In this commit, .ir.txt expectation test data files for the JVM IR
backend are renamed to .txt. This is done as two separate commits so
that Git would recognize that these files were logically moved, not that
the contents of the original .txt files were changed.
#KT-64680
Alexander Udalov