Both the new and old incremental compilation (IC) analysis rely on
Kotlin class metadata to detect a change.
However, Kotlin metadata currently doesn't contain info about
annotations (KT-57919), so the IC will not be able to detect a change
to them.
With this commit, we'll fix the new IC such that it can detect a change
to class annotations by not relying only on metadata.
We currently scope this fix to the new IC (cross-module analysis) first.
We'll fix this issue for within-module analysis later.
Performance: There seems to be no performance impact from this change.
Snapshotting the 400MB ideaIC-2022.1.4/app.jar takes 4.1s before and
after this change.
Test: Added ClasspathChangesComputerTest.testChangedAnnotations
^KT-58289: Fixed
JavaClassUseSiteMemberScope won't return a Java method getFoo if there
is an inherited Kotlin property foo in scope because calling this method
would effectively call the property accessor which is not possible in
Kotlin.
This commit excludes private properties from this consideration because
no accessor methods are generated for them, and so calling a Java method
getFoo is ok.
#KT-58577 Fixed
It's obviously expected that all overridden, not only direct ones
are considered
While it likely changes the behavior and some tests are expected to be
changed, original intention was to fix the behavior for other usages
(see later commits) and the part with tests are postponed with KT-58636
^KT-58636 Related
Java declarations do not have a file parent, their outer element is
IrExternalPackageFragment.
The test did not fail in K1 only by accident, because there's an extra
IrTypeOperatorCall on the property reference's dispatch receiver, which
automatically makes it non-inlinable. In K2, it's IrGetField, so we were
trying to compute if its dispatch receiver is inlinable and for that we
tried to get its fileParent, which resulted in exception if it comes
from Java.
Also refactor PropertyReferenceDelegationTransformer.canInline a bit.
#KT-57955 Fixed
The only place where it was used was revised input type logic for lambda
analysis, and it turns out the only significant information it carries
is the presence of expected type ref, which is in fact equal to such of
an expectedType argument
... in order to provide better guidance for projects
migrating to Multiplatform/SourceSetLayout v2 which will suffer from
`UnknownDomainObjectException` when requesting old Android source sets
like
```
sourceSets.getByName("androidTest") // renamed to androidUnitTest
sourceSets.getByName("androidAndroidTest") // renamed to androidInstrumentedTest
```
^KT-58488 Verification Pending
Also, this change adds SinceKotlin and Java.Deprecated to this phase
It fixes some problems with API_NOT_AVAILABLE, so now it is closer to K1
^KT-57648 Fixed
^KT-55723 Fixed
It has been marked as deprecated for a while and targeted to be deleted in 1.9.0
#KT-53781
Merge-request: KT-MR-10082
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
* Also, mention implementation details of EnumEntries to enable safe uses of a 'EnumEntries' as a set
* Fix testdata for opt-in marker in enum entries
^KT-58548 fixed
Merge-request: KT-MR-10037
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
We must generate transform method for `IrMemberAccessExpression` by
hand because of specifics of working with `typeArguments`. But we
also must consider the case that in future we can add new fields in
this element. If it happens, we will see error message.
#KT-57812
There was a bug with early return from `toConstantValue`
method when we found any const value in `ConstValueProvider`.
Actually we should return only if expected type match. This error can
occur if annotation and constant inside it are fakes and
have the same offset.
#KT-57812
The first one `IrConstExpressionTransformer` is responsible for
transforming ordinary expressions and the second one
`IrConstAnnotationTransformer` is responsible for annotations.
#KT-57812
Now JDK toolchain configures project level compiler options jvm target
convention and does not override convention for task.
For use case when toolchain is configured via task DSL jvm target
convention overrides project level convention.
^KT-57393 Fixed
Ilya Kirillov