We have an extra parameter in the mapped signature, and don't care about
Kotlin types there (so far). Might be a better idea to obtain the actual
descriptor for a suspend function (with extra parameter), and pass
arguments accordingly.
When we've determined that we are going to invoke an erased inline class
method ('static foo-impl(this, ...)' in inline class), keep track of it
so that the remaining type mapping logic proceeds correctly.
#KT-26998 Fixed Target versions 1.3.20
When mapping callable method signature for erased inline class methods,
use original function descriptor instead of super declaration
(otherwise it would map to a default interface method with mismatching
signature).
When generating delegates to Kotlin default interface methods, keep
track of the original Kotlin types for delegating method arguments and
interface method arguments.
'original' for value parameters of fake overrides points to the
overridden function value parameters instead of the value parameter of
the unsubstituted function. This causes inconsistent type mapping for
inline classes implementing generic interfaces with default methods.
#KT-25295 Fixed Target versions 1.3.20
#KT-26931 Fixed Target versions 1.3.20
We began to write version requirement on declarations with `Result` and
now (after bootstrap) we are getting error in this test because of that
version requirement.
see 908be10bf4
- Add marker for the experimental type inference features
- Add annotation that will control builder-like inference
- Require that annotation on corresponding parameters and extensions
- Allow to use builder inference without suspendability
Changes in tests and refactorings (rename mainly) are going to be
introduced in further commits
They are a kind of a hack applied in light-classes and it'd be nice
to prevent them being used in irrelevant contexts
kotlin-serialization-compiler module should not depend on idea,
thus we can't use annotations directly there.
So, we copy-paste them and add a test on names consistency
Otherwise, whether LazyLightClassMemberMatchingError happens
or other type of errors because serialization plugin expects
full resolution in the correct module
Currently, only @Serializable annotation leads to exceptions,
but just in case we consider both of them as potentially problematic
#KT-26895 Fixed
Dmitry Petrov