Lists have defined contracts for equals and hashCode and thus might be used as map keys for the sake of caching. Gradle's file collections do not follow those contracts, leading to cache misses and creating too many classloaders.
#KT-61426 Fixed
In partial module compilation, especially inside the IDE, only a few
files from the project are passed to fir2ir. FIR in these files might
contain references to declarations from other files.
As the FE doesn't usually care about called property initializers,
called properties might be resolved to 'CONTRACTS' or even 'STATUS'.
The backend, however, might need to inline constant expressions from
properties.
'CodeFragmentCapturedValueAnalyzer' assumes the analyzed code fragment
is then passed to the backend. For property calls, there are several
code generation strategies (field, accessor, delegate). In order to
be able to choose one, the whole property, including its possibly
'const' initializer, must be resolved.
The commit fixes a plenty of 'FirIdeNormalAnalysisSourceModuleCompilerF\
acilityTestGenerated.CodeFragments.Capturing' tests that broke after
the 'FirExpression.type' refactoring.
We should protect return types from value parameters/property accessors
and backing fields from repeatable modifications.
Such declarations can be modified during type resolution by
`transformTypeToArrayType` or property getter type propagation,
so we should be able to restore the original reference in the case of
exceptions (PCE for instance)
^KT-61422
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
This change expanded KAPT to support a new param
'fileAccessHistoryReportFile', which reports all the classes used during
annotation processing into a file, in the form of a list of URIs.
This is useful for build speed improvements described in https://engineering.fb.com/2017/11/09/android/rethinking-android-app-compilation-with-buck/.
Essentially, using the list of used classes, we can compile only
the dependencies that are really affected by the developer's
code changes and improve Kotlin build speed.
^KT-52853
Rename to "expect" and "actual" annotation.
This will be needed in next commit to make it clear that
only expect annotation value needs special handling.
^KTIJ-26700
It was reported because in composite module analysis we have both expect
and actual annotation descriptors, which may differ.
This may lead to bugs in the checker of ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT
diagnostic.
`fqName` comparison can be safely removed, because we already check
types in `areCompatibleExpectActualTypes`.
Tests:
- typealiasedAnnotation.kt - for annotation use (so it has different
ClassId)
- typealiasedAnnotationAsArgument.kt - when typealiased annotation
used in another annotation as argument
- sourceRetentionAnnotationsWhenTypealias.kt - tests same as
compiler/testData/diagnostics/tests/multiplatform/annotationMatching/sourceRetentionAnnotationsWhenTypealias.kt
No special test added for opt-in, because it's prohibited to have
expect/actual opt-ins by EXPECT_ACTUAL_OPT_IN_ANNOTATION checker.
^KTIJ-26700
Alexander.Likhachev