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.
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
1. Unify BinaryLibraryKind type and move it to TestSettings
2. Pass it via ClassSettings instead of constructor parameters.
3. Update GenerateNativeTests.kt to generate CExport tests as a matrix.
There are few reasons why fake overrides should not be printed:
1. Fake overrides are not serialized in metadata. So, if one will run
"dump-metadata" they won't see there any fake overrides. Neither
their signatures. It would be inconsistent if
"dump-metadata-signatures" command would show them.
2. In order to properly build fake overrides the KLIB tool needs
the dependency library with the super class or interface, which
is not available unless this is stdlib or one of the built-in
Kotlin/Native platform libraries. KLIB tool does not support any
reasonable means for passing dependencies through CLI arguments.
If such possibility is added in the future, it would be the
right time to support printing fake overrides (probably under
a separate CLI option).
^KT-62340
Don't print signatures computed for private declarations. This
effectively means that only signatures for `public`, `protected`,
and `internal` declarations will be printed.
Note: This new behavior is intact with `dump-ir-signatures` command.
^KT-62340
A class can inherit two declarations that are compatible from the
overridability standpoint and are therefore combined to a non-trivial
intersection.
At the same time, the class can declare a member declaration that
only overrides one of the intersection's members.
In this case, we break up the intersection and only add the overridden
parts to the declared member's direct overridden list.
If the class doesn't override the intersection, it exists as
intersection override, like before.
#KT-65487 Fixed
Dmitriy Novozhilov