When calling a generic Java generic method with vararg parameters with empty
vararg, incorrect array creation instruction was generated for primitive type:
NEWARRAY T_INT instead of ANEWARRAY java/lang/Integer. Here for Java method
public static <T> void takesVarargOfT(T x1, T... xs) {}
corresponding vararg parameter was considered to be of type 'Array<T>?',
which is not a non-null array type, so, NewArray intrinsic failed to generate
proper bytecode.
Treating special functions for `if`, `when`, `try`, `?:` as not accepting `Nothing` result type is incorrect.
Making so leads to cases with uninferred `Nothing` result type for inner calls and lost data flow info.
This commit fixes two issues in the existing implementation of translating primitive array types:
* IrType.getArrayElementType throws an exception when the receiver is a primitive array type, because IR expects primitive array types use symbols defined in IrBuiltIns, but fir2ir translation doesn't;
* IteratorNext.toCallable assumes all element types are boxed.
The first issue is fixed by changing the fir2ir type translation to use symbols in IrBuiltIns for primitive array types, and the second by not unboxing primitive types.
Here we introduce ONLY_IMPLICIT_RECEIVER tower level
to support extension lambda calls on local variables,
and soften extension receiver checks to make such extensions visible & applicable.
Also here we try to map arguments twice for functional types
Similar to references to error type, this may happen if library A uses
an entity from library B annotated with an annotation from C, but A is
compiled without C on the classpath.
Nullability constraints should not be chosen when proper
argument constraints for variables in contravariant position present.
^KT-32106 Fixed
^KT-33166 Fixed
Force constraint system completer to always fix variable with unknown position.
This makes inferred type for in parameters less specific, but OI infers to
subtype in such cases, so NI won't infer to less specific types than before.
Current selection of completion mode for call is not always correct in case of full mode,
and sometimes too conservative in case of partial mode. Updated algorithm checks constraints
wrt position of type variables in return type and in other related constraints.
Full completion happens if proper constraint requirements are satisfied for variables.
'descriptor -> descriptor.original' relation is often inconsistent
wrt 'containingDeclaration', parameters, and type parameters,
we have to introduce some workarounds here.
- Fix `toString` evaluation for unsigned types in FoldConstantLowering
- make corner cases around float/double evaluation work for K/JS
- remove usage of kotlin type
Dmitry Petrov