Native bitcode files were moved out of the stdlib to the default
location of bitcode files in the dist.
Now it is possible to build stdlib separately and once as a klib
without bitcode files inside.
The problem here is that for common session we register `FirJavaElementFinder`
which provides light classes based on expect classes. And then
at the start of analysis of jvm module we register one another
`FirJavaElementFinder`, which sees actual classes and uses them to
build light classes
But, because class ids of expect and actual class pair are the same and
element finders are ordered by creation order, when java resolve tries
to resolve some class, it founds light class based on expect class,
even if we are already in platform session
To fix this problem, it was decided to unregister all previous element
finders on creation of each new session, so old finders won't interfere
with analysis
^KT-63612 Fixed
^KT-64296
This commit addresses a scenario where an 'actual' declaration is marked
with a Deprecated annotation at the 'Hidden' level, while the
corresponding 'expect' declaration is not. When resolving,
'CheckHiddenDeclaration' marks the 'actual' declaration as unsuccessful,
leading to the selection of the 'expect' declaration as the successful
candidate.
'FirDeprecationChecker' handles a case where an 'actual' class is
annotated with Deprecated, but the 'expect' class is not. During the
checking of the 'actual' class constructor, 'CheckHiddenDeclaration'
skips it due to the absence of a direct Deprecated annotation.
'FirDeprecationChecker' then identifies this constructor and reports a
DEPRECATION_ERROR.
'FirDeprecationChecker' will now be applied to solving problems related
to 'actual' declarations with corresponding Deprecated annotations. The
process remains the same: 'CheckHiddenDeclaration' will skip the
'actual' declaration, and then 'FirDeprecationChecker' will identify it
and report the error.
^KT-61792 Fixed
Objective-C has a special type, "instancetype". Generally, it is a type
that matches the method receiver type. So, if `Foo.foo` method returns
`instancetype`, then `Foo.foo()` would be of type `Foo`, while
`Bar.foo()` would be of type `Bar` (where `Bar` is a subclass of `Foo`).
Surprisingly, `instancetype` can be used not only as a return type, but
also somewhere inside a return type. cinterop wasn't ready for this.
This commit expands implementation of `instancetype` in cinterop to
cover more cases.
^KT-59597 Fixed
This particular test references kotlin.reflect.KProperty1 both in
common and platform sourceset. And if there is no stdlib in dependecies
it resolves to KProperty1 from builstins, which is expect (see KT-64061),
which leads to broken expectations that after IR actualization there
are no referenced expect classes
.ir.txt file may be absent for the following test kinds with // DUMP_IR
- codegen tests with // IGNORE_BACKEND_K1: ANY
- FirScriptCodegenTestGenerated, since it does not have K1 counterpart
- Fir*PluginBlackBoxCodegenTestGenerated, since it does not have K1 counterpart
^KT-64256 Fixed
MT stands for "modularized tests"
^KT-64166 Fixed
Review: https://jetbrains.team/p/kt/reviews/13517/timeline
This commit fixes:
java.lang.IllegalArgumentException: Local <local>/<anonymous> should never be used to find its corresponding classifier
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl.getFirClassifierByFqName(FirProviderImpl.kt:252)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl$SymbolProvider.getClassLikeSymbolByClassId(FirProviderImpl.kt:60)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.computeClass(FirCachingCompositeSymbolProvider.kt:131)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.access$computeClass(FirCachingCompositeSymbolProvider.kt:27)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:75)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:69)
at org.jetbrains.kotlin.fir.caches.FirThreadUnsafeCache.getValue(FirThreadUnsafeCachesFactory.kt:40)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.getClassLikeSymbolByClassId(FirCachingCompositeSymbolProvider.kt:158)
at org.jetbrains.kotlin.fir.resolve.transformers.mpp.FirExpectActualResolver.findExpectForActual(FirExpectActualResolver.kt:41)
Static scope is checked first during resolution
(scopes are in reverse order).
This fixes a difference between how K1 and K2 resolve annotations.
#KT-63249 Fixed
With the directory structure similar to one of a multiplatform library,
where each source set sources are placed into the directory
named after this source set.
Do not use legacy projects for building relative paths
Nataliya.Valtman