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
For some reason type parameters end up in
`GlobdalDeclarationTable`, and thus we tracked them in
`IdSignatureClashDetector`, which wasn't right and confused the
diagnostic renderer that uses
`org.jetbrains.kotlin.resolve.MemberComparator` for sorting the
declarations to display in diagnostics. That comparator doesn't know
jow to work with type parameters.
Besides, type parameters, like many other types of declarations, are not
considered public wrt KLIB ABI, so there's no need to show
CONFLICTING_KLIB_SIGNATURES_ERROR for them.
^KT-65723 Fixed
Show what kind of declarations exactly are clashing: functions,
properties, or fields.
This is so that diagnostics about clashing properties and fields are
distinguishable from one another, since properties and fields
are rendered the same way in those diagnostics:
We only want to report signature clashes for declarations that come
from the module currently being serialized. In GlobalDeclarationTable,
declarations from other modules could also be stored.
Checking whether a declaration is a Lazy IR declaration to
determine if it comes from an external module works okay, but it is
a hack which relies on an implementation detail of IR, which may or
may not work in the future.
Use a more robust logic here, since IrFileSerializer is always aware
which declarations are declared in the current module and which are
just referenced from it.
If we encounter a declaration in the current module whose signature
is the same as that of a declaration in another module which we happen
to also reference from the current module, don't report any errors,
just like we don't do it in Kotlin/JVM. This leaves the user in the KLIB
hell situation, but this is intentional, because otherwise a legitimate
change like moving a declaration to another module and marking
the original one as `@Deprecated("", level = DeprecationLevel.HIDDEN)`
would lead to a error, and we don't want that.
Also, don't try to show the diagnostics on a declaration that doesn't
have an IrFile.
^KT-65063 Fixed
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 is more convenient behaviour for debugging with klib-tool than
just failing.
Note that enabling Partial Linkage globally in klib-tool is undesirable,
as it can auto-tweak IR (e.g. when overrides do not match), thus
distorting the rendered IR
^KT-61143 Fixed
Now, we detect clashing signatures during serialization to KLIB and
report a compiler error if two or more declarations have the same
`IdSignature`
For example, for the following code:
```kotlin
@Deprecated("", level = DeprecationLevel.HIDDEN)
fun foo(): String = ""
fun foo(): Int = 0
```
the compiler will produce this diagnostic:
```
e: main.kt:1:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
e: main.kt:4:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
```
Note that we report this diagnostic during serialization and not earlier
(e.g., in fir2ir) for more robustness, so ensure that we check
exactly the signatures that will be written to a KLIB.
If we later introduce some annotation for customizing a declaration's
signature (e.g., for preserving binary compatibility), this
diagnostic will continue to work as expected.
^KT-63670 Fixed
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.
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
IrCapturedType (which is a IrSimpleType) does not have variance, so it
is confusing to have it in IrSimpleTypeBuilder, and it's clearer to
construct type projection separately anyway.
- use identity in equals/hashCode. It was already effectively working
like this because of `constructor === other.constructor`
- implement variance and declare it in IrSimpleType
- remove obsolete TODO
- simplify code in captureFromArguments
- use data objects
IrStatementOriginImpl and IrDeclarationOriginImpl were made final
classes to simplify the creation of them (a delegate provider was
added) and to optimize performance when comparing the origins by type
and name
A full mangled name of a declaration is a mangled name that includes
the mangled names of all the declaration's parents.
We don't use full mangled names for building `IdSignature`s. We use them
in two places:
- Generating stable names for JavaScript functions in Kotlin/JS
(see `NameTables.kt`)
- Generating names for LLVM symbols from lowered IR functions in
Kotlin/Native (see `BinaryInterface.kt`)
In both of these places we run the IR mangler, hence we don't need this
functionality in other manglers.
Ideally, instead of this method, there should be a link
to IrModuleFragment. Unfortunately, it would require to big refactoring,
as some of IrPackageFragment implementations doesn't have any
IrModuleFragment inside, and are not located inside any
IrModuleFragment.
So for now, we just implement and use everywhere a single way of
getting the module descriptor, which respects a IrModuleFragment
link if it exists, and fallbacks to descriptor-based method
if it doesn't.
^KT-62623
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
It has been renamed to IdSignatureFactory. We have to keep
IdSignatureSerializer as a typealias for a while to keep the source
compatibility with the Compose compiler plugin.
Now there is separate class encapsulating logic about how to build
fakeOverrides and one encapsulating logic of which classes
do need building fake overrides.
This also allows to untie strange inheritance dependencies.
^KT-61934
Previously, it had some internal state that was saved between calls
and needed to be cleared.
This state was eliminated, which makes invariants clearer and using
easier.
^KT-61934
`FakeOverrideBuilder.provideFakeOverrides` recursively changes overrides
for all superclasses in the hierarchy, including lazy IR, which is a lot
of extra work.
Also it leads to some tests failing in the IR fake override builder mode
because it changes correct fake overrides of Java classes to incorrect
ones. Those tests are unmuted but it doesn't mean they are fixed -- most
likely we'll generate fake overrides via IR for lazy IR too, at which
point they'll start to fail again.
Dmitrii Gridin