Before that commit, function in coroutine implementation class was
override for both SuspendFunctionN's and FunctionN+1's invoke,
which somehow works, but breaks exporting classes with such functions.
Now it's two separate functions, as it should be normally.
^KT-49395
Such type cannot be cast to a base type, if the former is loaded from
a different, parent classloader.
#KT-47857 Fixed
Co-authored-by: Aleksei.Cherepanov <aleksei.cherepanov@jetbrains.com>
The coroutine method transformer extends the range of locals
across code where the local is not live when it is safe to do
so. However, it only bailed out for one case of control-flow
merging, namely backwards branches for loops. That is not
sufficient as there can be control flow merges without loops
where the local is only defined on one control-flow path.
This change generalizes the bailout to any control-flow merge.
^KT-49834 Fixed
Timelimit is increased from 1.5 to 3 minutes because in some cases
(in parcelize tests) on windows tests can don't fit in 1 minute
limit, which causes flaky failures of tests
Value of 3 minutes is taken from old parcelize tests
There is one of checks left unimplemented (FirParcelizePropertyChecker.checkParcelableClassProperty)
because it requires huge commonization of detecting which type can be
serialized and which not, which is not prioritized job for now
Methods `needToGenerateAdditionalMembersInClass` and
`needToGenerateNestedClassifiersInClass` are removed, now compiler
uses `get...Names` and `getTopLevel...` methods to determine which
extension may generate declaration with specific classId/callableId
This is needed to simplify API of FirDeclarationGenerationExtension and
provide guarantee that `generate...` method will be called with
specific classId/callableId only if specific extensions returned name
for this id from `getName...` functions
Existed code might lose declarations in two cases:
1. When there is a declared function which is mapped to property
(java synthetic properties)
2. When class has property and function with same name
This is needed for two reasons:
1. Before this change companion object appeared in FirRegularClass
twice: in declarations list and in companionObject field. This may
trigger twice transform of it
2. It's very hard to implement generation of companion object by plugins
because if it is part of the tree then generated declaration must be
registered in FirProvider, which is inconsistent with other generated
declarations. Replacing FIR with symbol and removing custom logic of
visiting/transforming companion FIR allows us to just replace companionSymbol
in FirClass if plugin wants to generate it without any additional work
Igor Chevdar