This is needed for two reasons:
1. Before this change companion object appeared in FirRegularClass
twice: in declarations list and in companionObject field. This may
trigger twice transform of it
2. It's very hard to implement generation of companion object by plugins
because if it is part of the tree then generated declaration must be
registered in FirProvider, which is inconsistent with other generated
declarations. Replacing FIR with symbol and removing custom logic of
visiting/transforming companion FIR allows us to just replace companionSymbol
in FirClass if plugin wants to generate it without any additional work
If some java class has multiple supertypes then we need to collect
overriddens from all those types directly, even if superTypeScope
(which is FirTypeIntersectionScope in this case) returns only
one symbol from one of this types (not intersection one)
This is needed to proper enhancement in cases when some type occurs
multiple times in supertypes graph with different nullability
of arguments:
class ConcurrentHashMap<K, V> : AbstractMap<K!, V!>, MutableMap<K, V>
If we try to find method `get(key: K): V` supertype scope returns
`AbstractMap.get(key: K!): V!` (because it actually overrides
`MutableMap(key: K): V?`), but we need to get both symbols to
properly enhance types for `ConcurrentHashMap.remove`
This is needed for debug purposes, because without classId or reference
to class it's very hard to understand which scope you are observing
in debugger
Ensure that the attribute com.android.build.api.attributes.AgpVersionAttr
is not published when creating the android usage contexts.
^KT-49798 Verification Pending
This test publishes a Multiplatform/Android library locally with
a given AGP version (7.1-*+) and tests the compatibility with older
AGP consumer versions.
Two projects will be tested:
multiplatformAndroidConsumer:
kotlin("multiplatform") + android target depending on
the previous publication as 'commonMainImplementation' dependency
plainAndroidConsumer:
kotlin("android") depending on the previous publication
as 'implementation' dependency.
Both projects will test the 'assemble' umbrella task to ensure,
compatibility with the given publication.
^KT-49798 implicitly covered as well