Without it, the lazy body of code fragment is not properly resolved
and cannot be analyzed
Use the correct function from `BodyResolveContext` to take the scopes
from code fragment into account
^KTIJ-27879 Fixed
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.
Since JDK 17+ pretty-printer does not print parens on empty annotation
parameters, print them anyway. Otherwise, tests with annotations differ
on different JDKs.
#KT-57389
Previously, some tests have also been disabled on JDK 11+, since
we did not filter out empty filesets, which led to failed assertion
inside JDK.
#KT-57389
This is the case when we have Java class in hierarchy. In this case,
we want to generate reflective access to the original Java method.
#KT-63642 Fixed
When compiling code fragment, we forbid to use `irLinker` as
IR provider. Because of that, if there are some plugin
extensions, we will not be able to find deserializer
for a given module and will fail.
#KT-63695 Fixed
As a file annotation container is required for resolution,
it should be closer to the resolution logic. Now only LLFirTargetResolver
will operate this logic, so we can change the logic in the future without
a big refactoring.
E.g., as the next step, this resolution can be integrated to the file
^KT-63042
This entry point is required to be able to pre-resolve dependency
declarations.
E.g., fake override declaration shares annotation instances between
the original and the fake one, so we should resolve the original
firstly to avoid concurrent modification and correct context.
This will be done later.
This commit effectively only drops body resolution for a file annotation
container if the target element is not a file because this
is not required for correct resolution
^KT-63042
To make it possible to change nullability of IrCapturedType and change
its annotations, which is happening when determining overridability of
functions via IR.
#KT-63437 Fixed
IrCapturedType (which is a IrSimpleType) does not have variance, so it
is confusing to have it in IrSimpleTypeBuilder, and it's clearer to
construct type projection separately anyway.
- use identity in equals/hashCode. It was already effectively working
like this because of `constructor === other.constructor`
- implement variance and declare it in IrSimpleType
- remove obsolete TODO
- simplify code in captureFromArguments
- use data objects
getServiceIfCreated doesn't create a service instance if id wasn't
created before. There are no other service requests for
KotlinLabelProviderService, so it was not used for file types.
KTIJ-27755
Ilya Gorbunov