We want to forbid expressions of type `Unsigned == Unsigned` or
similar. Working with unsigned numbers we can only inline them on the
call site or use in `String.plus` expression.
This commit fixes problem in test `unsignedTypesInAnnotations`. Here
interpreter thinks that expression `ONE_UINT != 1u` can be
evaluated, but fails to do it. This fail prevent us from inlining
`ONE_UINT` and on runtime we get error about missing getter.
Earlier this property would have been inlined by `ConstLowering`,
but we got rid of it.
It basically can be replaced with IR interpreter. The only half-hack
was required in `PropertyReferenceLowering`. Const interpreter is
running before it, so we can't optimize some calls on const
properties that appear after this lowering. Solution is to inline
constants manually during property reference lowering.
This will help in some lowerings which need to change the callee of a
call. Instead of creating a new call and copying everything (type
arguments, value arguments, receivers, annotations, attributes, ...),
it's easier to modify the `symbol`. In a way, this is a continuation of
22b4b29292.
Resolve the version of the annotation processor path (specified in annotationProcessorPaths) in kapt plugin if it is already specified in dependencies of this module or parent module. Plugin management is also supported.
#KT-59521 In Fixed
Merge-request: KT-MR-10761
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
According to the preloader's "-measure" option, just the raw class files
occupy ~50 Mb during compilation of hello world (~55 Mb for K2). So 32M
is a very outdated value for Xms. This change sets it to something more
reasonable to hopefully avoid unnecessary GCs and thus help with
performance and potentially with OOMs (KT-58690).
#KT-58690
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>
Ivan Kylchik