Currently, `SpdxSbomTask` declares output file not as `@OutputFile`, but `@OutputDirectory` leading to overlapping outputs problem. This way the problem is worked around.
#KTI-1221 In Progress
Their attribute sets are the same as for platform-specific publications, thus Gradle raises a legit deprecation warning here. These configurations are not being consumed directly, so it's fine to make them not consumable
#KTI-1221 In Progress
Add some more filters on private/synthetic stuff (which doesn't matter
in practice) to make full and light analysis mode dumps as similar as
possible, so that all existing tests will pass for JVM IR. Unmute some
tests which were failing with the old JVM backend.
Tests on repeatable annotations are muted because in full analysis,
annotations are wrapped into the container (e.g. `@A(1) @A(2)` ->
`@A$Container(A(1), A(2))`), but they are no in the light analysis mode.
So there's always going to be a difference for these tests between full
and light analysis, unless we're going to change behavior of kapt, which
would be a kind of a breaking change.
#KT-58497 Fixed
Do not compare private and synthetic methods between full and light
analysis modes, some private fields, and InnerClasses attributes. This
is needed to prepare these tests for migration to JVM IR.
Similarly to how stub bodies are generated for functions in the kapt
mode (see `BodyGenerator.generateFunctionBody`).
This is more useful then not generating bodies at all, because otherwise
in the -Xjvm-default=all/all-compatibility modes it would be difficult
to differentiate functions with default implementations from the ones
without (because they all would lack body and thus be generated as
abstract into the resulting Java stub).
The effect of this change is pretty minor, so there's no YT issue. But
it fixes light analysis tests run with JVM_IR in
`codegen/box/jvm8/defaults`, because now there's no difference between
full analysis and light analysis for interfaces with default methods in
new modes.
To make these tests behave closer to kapt, since kapt is the primary use
case for the light analysis mode.
AbstractLightAnalysisModeTest compares the text dump of bytecode
obtained with full analysis and light analysis, removing things like
anonymous/synthetic entities. In the light analysis mode anonymous
objects in supertypes are always approximated, and in the full analysis
mode they are always present as is in signatures. So we're transforming
the text dump in the same way, by approximating anonymous objects in
signatures (more precisely, in return types of methods and fields) to
the supertype.
This is needed in order to run light analysis mode tests for JVM IR
backend. In the subsequent commit, this extension is added to light
analysis mode tests.
Kapt stub generation uses this extension to transform local types to
non-local:
private val x = object {}
With this extension, x's type will be `Any`. Without it, it will be an
anonymous type. This anonymous type was not a problem for the old JVM
backend, but it's difficult to translate it in the IR infrastructure in
the light analysis mode where bodies are not resolved.
When kapt stub generation works with JVM IR enabled,
KaptAnonymousTypeTransformer ensured that backend would not crash and
stubs would contain something useful.
However, this is not happening in light analysis mode tests, which are
supposed to check how compiler behaves in the light analysis mode which
is used in kapt.
Avoid expensive calls to `navigationElement` for methods
that cannot be getters/setters and would be filtered later.
Repeat partly naming generation strategy.
Merge-request: KT-MR-10689
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
XCTest test binary is a bundle plug-in that is similar to a framework.
This is a part of ^KT-58928
Merge-request: KT-MR-10662
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
supposedly, when search for package is performed,
it's performed multiple times with different names
but for the same scope.
In this situation, extracting scope from key brings a lot of memory.
For IJ, it reduces load from 7Mb -> 4Mb
IR inliner should evaluate `apiVersionIsAtLeast` on compile-time (except
cases of inlining to inline functions from kotlin runtime) just as
bytecode inliner does.
^KT-59291: Fixed
This implementation of `finalize()` is incorrect. See: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Object.html#finalize()
> If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.
> If a subclass overrides finalize it must invoke the superclass finalizer explicitly.
Instead of providing help by highlighting the tests that forget to clear the temporary directories, this `finalize()` causes OOM.
Merge-request: KT-MR-10756
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
A designation path for synthetic declarations like fake override
or member delegate contained the wrong FirFile, because it
was provided by the original declaration that is wrong.
So we should pick up the file from our path, because it shouldn't be
synthetic
^KT-59505 Fixed
FIR expressions rendered by FirRenderer don't look very nice in error
messages anyway, and additionally, they can become arbitrarily large,
so we shouldn't use them in messages.
#KT-59449 Fixed
Alexander.Likhachev