- Use direct access to property defined into companion object when
it is possible rather than always use an accessor to access the
property.
- Use direct access will speedup runtime performance.
- Avoid to generate useless accessors for companion properties.
Fix of https://youtrack.jetbrains.com/issue/KT-14258
Note, that this change potentially has some other effects in corner cases
(like the changed test data that is rather sensible because `bar`
in the example is not effectively projected out and can be called
with nulls)
Probably, we need to consider rewriting all other isSomeType methods
in KotlinBuiltins, but now it seems to be a rather dangerous change
#KT-16424 Fixed
Otherwise if Char value is a result of some erased generic call,
coercing it to I (primitive int) causes CCE at run-time.
#KT-23104 Fixed Target versions 1.2.40
* Generate missing IR parameter declarations in external stubs
* Use origin = FAKE_OVERRIDE in external IR stubs for fake overrides
* Set .parent in external IR stubs
* Set .parent in IR generated by some utility methods
Property accessor that overrides a non-default property accessor with
visibility different from the property visibility was incorrectly
considered "default". Corresponding metadata was written incorrectly,
and 'internal' setter call caused NSME
#KT-23044 Fixed Target versions 1.2.40
Such references require proper scope so that local symbols are bound.
Example:
```
fun <T> outer() {
abstract class ALocal<S : T> {
abstract fun bar()
}
class Local<S : T> : ALocal<S>() {
override fun bar() {}
}
}
```
Here local classes have type parameters with upper bounds depending on
function type parameters, and members overriding members in other local
classes.
Introdude deprecation as per KT-21515. Warning is reported on type
usage, that soon will became invisible. Quickfix by adding explicit
import is added.
Idea behind implementation is to mark scopes that are deprecated (see
ClassResolutionScopesSupport).
Then, during walk along hierarchy of scopes, look at deprecation status
of the scope that has provided this classifier.
Note that we also have to check if there are *some* non-deprecated
visibility paths (because we can see classifier by two paths, e.g. if
we've added explicit import) -- then this type reference shouldn't be
treated as deprecated.
Note that there are more places where assertions for inline classes should refined:
- lateinit vars
- values that come from Java
- type casts (interfaces to inline class type)
Probably, it would be more correct to skip such lambdas when resolving
the returns' references, but it'd be more complicated and still useless
since non-local returns are impossible in such lambdas
(relevant parameter is noinline)
#KT-22900 Fixed
- Into PrimitiveNumberRangeLiteralRangeValue modifies how bounded
value are created by checking if the high bound range can be modified
to be exclusive instead of inclusive such as the generated code will
be optimized.
- Add black box tests checking that the specialization does not fail
on any kind of arrays.
- Add a bytecode test checking that the code is correctly optimized.
Fix of https://youtrack.jetbrains.com/issue/KT-22334
In an open expected class inheriting an expected interface, abstract
members are now inherited as _open_ fake overrides, not final. Final was
technically safer but also stricter and thus could be unexpected by the
user. In a final class, abstract members are still inherited as _final_
fake overrides. So, the general rule is now the following: the modality
of an expected fake override, which overrides only abstract members, in
a non-abstract class is equal to the modality of that class
#KT-22031 Fixed
Probably, when NI is there this fix will become unnecessary because
there will be no approximation applied, thus the value parameter
will remain Hello<#Captured> instead of Nothing
#KT-17171 Fixed
Jake Wharton