Those fields were effectively marked as child elements after refactor.
However, because of the current (to possibly be changed) configuration,
the generator did not write accept methods for them.
In the IR generator, we had a so-called `ConfigModel` with classes like
`ElementConfig` and `FieldConfig` that we deal with during
tree configuration in `IrTree.kt`, and another kind of model called
just `Model` that included the `Element` and `Field` classes
correspondingly. Those were used for actual code generation.
After configuration, `ConfigModel` was transformed to `Model` and
then the code generation was performed using `Model`.
This architecture is overly complicated and results in massive code
duplication. Most `ElementConfig` and `FieldConfig` properties had
exactly the same counterparts in `Element` in `Field` classes.
So, if you wanted to add a new feature to the tree generator, you had to
add a property to both `ConfigModel` and `Model`.
Turns out we can do just fine with only one kind of model.
This class enables printing the import list in generated files
in a smarter way.
Also, refactor `Importable` interface hierarchy, namely, don't inherit
`TypeRef` from `Importable`, since we have types like `TypeRef.Star`
which are not really importable.
Replace the `Importable#typeWithArguments` property with
the `TypeRef#render` method to utilize `ImportCollector` while rendering
types.
Accessing list of declaration may trigger lazy declaration list computation for lazy class,
which requires computation of fake-overrides for this class. So it's unsafe to access it
before IR for all sources is built (because fake-overrides of lazy classes may depend on
declaration of source classes, e.g. for java source classes)
So this OptIn is needed to carefully handle all cases of .declarations access in FIR2IR
- Don't inherit `AbstractField` from `Importable`, because it really
is not
- Remove the `arguments` and `nullable` properties from `AbstractField`.
Both properties can be derived from the field's `typeRef`.
- Make `AbstractField`'s `typeRef` property of type
`TypeRefWithNullability` instead of just `TypeRef`, because fields
can always be nullable.
Ideally, instead of this method, there should be a link
to IrModuleFragment. Unfortunately, it would require to big refactoring,
as some of IrPackageFragment implementations doesn't have any
IrModuleFragment inside, and are not located inside any
IrModuleFragment.
So for now, we just implement and use everywhere a single way of
getting the module descriptor, which respects a IrModuleFragment
link if it exists, and fallbacks to descriptor-based method
if it doesn't.
^KT-62623
Sergej Jaskiewicz