- Move out getAnalyzerServices from FirFrontendFacade to TestSetupUtils
- Simplify DependencyListForCliModule. Now it takes BinaryModuleData as input
- FirOutArtifact contains several FirOutputArtifactPart
- Simplify FirFrontendFacade
This change is necessary for testTypeAliasExpansionRepeatedAnnotations
to work properly (otherwise we don't check a property at all). Before
current changes, the test worked thanks to accessors analysis which is
now OFF because of source kind check.
In particular, JVM IR doesn't provide KtFile for a multifile facade in
JvmDeclarationOrigin (JVM backend provides KtFile of a random multifile
part). This led to multifile classes being completely ignored in the
JVM_IR version of kapt. Now they are generated correctly and the changed
test passes, but there's a _ir.txt expectation file because the order of
'foo' and 'bar' is different (which is not a problem).
This is a hack to implement KT-32596 in the JVM IR version of kapt.
Basically we allow psi2ir to generate annotations whose classifier is
error class, which happens when it's unresolved. Because there's no
physical IR for an error class, we create stub IR for it via
SyntheticDeclarationsGenerator in case we'll need it.
With this hack, annotations with unresolved classifiers magically
survive all the way until the codegen (with a minor change in
IrBasedDescriptors) where they are generated as
`@error.NonExistentClass`, which then gets corrected by the kapt's
"correct error types" mode as in all other cases of error types.
Use the property as PSI element origin for delegated property accessors
and field in JVM IR as it is done in the old JVM backend. Otherwise kapt
"correct error types" mode can't find the property type and thus cannot
succeed in "resolving" it, which led to java.lang.Object being used as a
fallback.
Note that in the unmuted test, .txt and _ir.txt dumps differ only in an
unrelated NotNull annotation on a delegate field.
See also KT-37586 for some related changes which fixed this problem
initially in kapt.
Previously, we didn't close caches if incremental compilation failed.
The assumption was that we would fall back to non-incremental
compilation, where it shouldn't matter whether caches were closed or not
as non-incremental compilation should be able to recover from a
corrupted state of the caches.
However, this choice might have caused issues such as KT-55709 where
non-incremental compilation fails after fallback.
In this commit, we will now always close the caches before falling back,
just to be safe.
TODO:
1. We'll need to verify whether not closing the caches was the actual
cause of KT-55709, and that this commit fixes it.
2. Even if this commit fixes the issue, we'll need to see why
non-incremental compilation fails to recover from unclosed caches
(it would remain unsafe if that was not addressed).
^KT-55709 In progress (see TODO #1 above)
`FirDeclarationGenerationExtension.generateClassLikeDeclaration` was split
into two functions: one for generating top level classes, and one for
nested classes. Such change reduces verbosity and error-proness of
this extension and also allows to smoothly run plugins on local classes
^KT-55248 Fixed
^KT-55788
Test `parameter_jvmInline.kt` is removed because now members with value
classes are not included in light classes and don't have PSI representation
Artem Kobzar