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
This is needed to avoid problems with checking visibility of types which
are used in supertypes during supertypes resolution in IDE, when
supertypes of some class can be already computed, but not saved in
class itself, but still lay in supertypeComputationSession
There were 4 failing tests before this changes (all in
`DiagnosisCompilerTestFE10TestdataTestGenerated$Tests$Exposed`):
- testInternal
- testInternalAndProtected
- testProtected
- testProtectedSameWay
See the class at org/jmock/Expectations
public <T> T with(Matcher<T> matcher);
public boolean with(Matcher<Boolean> matcher);
When we extending such class it we start assuming
that fake generic override overrides both of the overridden that is wrong
from POV of Java and it fails at FIR ultimate build
NB: It's hard to write a test because such Expectation-like
class is impossible to write in pure Java
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Split some delegating scopes to basic and name aware implementations
Also get rid of getContainingCallableNamesIfPresent and
getContainingClassifierNamesIfPresent functions because they are not
needed anymore
1. Inner class constructor should have its outer class as a dispatch
receiver, since it is necessary for the call. Before it was null
2. Substituted inner class constructor should have its original dispatch
receiver type with the proper substitution. Before it was set to the
class itself (since the class was usually passed as a new dispatch
receiver)
Also, modify FIR renderer, so it properly renders the dispatch receiver
of the constructors
Assuming Java class `Super` has a protected `getName` method and a
public `setName` method.
Then, in a subclass of `Super`, FE1.0 allows calls to `setName` via the
property syntax if the property is protected and invisible due to
dispatch receiver is not `this` or `super`.
Dmitriy Novozhilov