The previous implementation had issues with
locks, publication and performance
Also, this change fixed a problem with mixed cycle inheritance
^KT-56550
^KTIJ-25430 Fixed
^KTIJ-23520 Fixed
^KT-57623 Fixed
^KTIJ-25372 Fixed
^KT-58357 Fixed
This is needed for signature tests to work with the same golden data
on both K1 and K2, since sometimes K1 and K2 produce IR with different
order of declarations and supertypes.
It was used to get importing scope, so it was renamed to getImportingScopeContext.
It was broken after changing the behaviour of `LowLevelFirApiFacadeForResolveOnAir.onAirGetTowerContextProvider` for the whole file
^KT-57966
Only Fir2IrJvmResultsConverter respected
the IGNORE_FIR2IR_EXCEPTIONS_IF_FIR_CONTAINS_ERRORS test directive.
Fir2IrJsResultConverter didn't.
This is fixed here.
... using .toList():
Using ListProperty.get() can return List implementations
that do not play well with CompilerArguments.
In this particular case RegularImmutableList from guava was returned
which later failed in the copyBeanTo function
^KT-58427 Verification Pending
* @ExperimentalForeignApi for all declarations that operate on
unmanaged memory (i.e. pointers and references)
* @BetaInteropApi for the rest of the interoperability declarations,
namely Swift/CInterop-specific interfaces and convenience-functions
### Implementation details
* Some typealiases are not marked explicitly because it crashes the compiler,
yet their experimentality is properly propagated
* License header is adjusted where it previously had been existing
* Deprecated with ERROR interop declarations that are deprecated for more than
two years are removed
* WASM target interop declarations are deprecated
* Deliberately make Boolean.toByte and Byte.toBoolean foreign-experimental to scare
people away
^KT-57728 fixed
Merge-request: KT-MR-9788
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Previously, updateTypeInBuilderInference was calling
updateTypeFromSmartcast to actually perform type update in
implicit receiver after stub types was inferred
Such action results in creation of following FIR:
FirSmartCastExpression(
original=FQAE(FirImplicitThisReference, typeRef=R|Inv<Stub>|)
typeRef=R|Inv<String>|
)
in receiver position during completion of calls
However, it wasn't the case in general situation due to
action of FirStubTypeTransformer, which, in turn visits and updates
type ref inside original expression, but only if there was at
least one call (that was completed) using that implicit receiver
As after such type update updateTypeFromSmartcast function does
nothing
Yet in situation, when there was only partially resolved calls
referencing that implicit receiver we actually create smart-cast
expression and don't update type
The change just removes usage of updateTypeFromSmartcast and
replaces is with direct type update
We still mutate state of implicit receiver, potentially
improperly, it should be addressed in future
^KT-54708
^KT-58365 Fixed
Yahor Berdnikau