The test used to fail because it has an augmented assignment for
elements in a HashMap of Strings, and "plus" fails to resolve due to
ambiguity: besides String.plus, BigDecimal.plus in the standard
library is also considered. BigDecimal is not resolved and thus
isError returns true. During type checking, the context has
isErrorTypeEqualsAnything set to true, and BigDecimal is now regarded
as a super type of String and BigDecimal.plus is a valid
candidate. Adding the directive "FULL_JDK" enables resolving of
BigDecimal so that BigDecimal.plus is excluded.
Now FE IR -> BE IR transformation is performed in multiple stages
controller by Fir2IrConverter. Stages are
* files & classes registration
* supertypes & type parameters handling
* functions & properties signature generation
* body generation
After each step we have guarantee (with exception of local classes &
type inference combination, and external symbols) that required symbols
(class/function/property/variable/type parameter)
are already bound to real declarations and have correct parents.
This commit also fixes incorrect parents for local classes
- Extract all backend codegen tests that specifically target behaviour
in to-be-deprecated functionality from language versions < 1.3"
- Remove those tests from the JVM IR test suite.
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
This fixes the most common (and rather annoying) bug in augmented
assignment desugaring with collection element receiver.
Fix is somewhat hackish: introduce an intrinsic for MutableMap.set,
thus bypassing discrepancies in 'get' and 'set' call generation.
Fixing it properly requires design decisions for corner cases where
ad hoc augmented assignment desugaring with collection element receiver
"accidentally" works, producing identical objects and vararg arrays for
arguments of 'get' and 'set'.
When generating collection element receiver (such as 'a[i]'), accessible
descriptor for get/set operator should be used.
Otherwise, if the corresponding get/set operator fun is called via an
accessor, its argument types may be different in case of generic fun
specialized with primitive types.
#KT-20387 Fixed
Juan Chen