Previously we inferred "open" if there was at least one open member in the
hierarchy. However, that's not correct when that member is overridden by
another member in the hierarchy which is abstract. This led to incorrect code
being accepted by the front-end, and an exception during the bridge generation
#KT-12467 Fixed
In an expression such as "Obj::class" where Obj is an object, it's fine to
consider Obj either an expression or a type and generate either
Obj.INSTANCE.getClass() or Obj.class correspondingly. However,
the former fails in the object's super constructor call because the INSTANCE
field is not yet initialized. Thus, we force generation of Obj.class in case
when Obj is an object.
Note that this has been reproduced in our project, see
KotlinMetadataVersionIndex
- Inline the usage of ExpressionCodegen#generateClassLiteralReference into
ClosureCodegen, simplify
- Support DoubleColonLHS.Expression in generateClassLiteralReference
- Substantially simplify KClass.java intrinsic by reusing
generateClassLiteralReference
#KT-13075 Fixed
#KT-12995 In Progress
As well as for other kinds of expressions
Within attached test they were generated twice in case of last expression of coroutine block,
because coroutine related codegen part is built upon assumption that all expressions should be generated lazily
Also add a test about unary postfix increment/decrement
#KT-13156 Fixed
Following the TODO in CallableReferencesResolutionUtils.kt, delete the
suspicious scope and use the new resolution process with the qualifier which
was obtained after the resolution of LHS. However, by default the tower
resolution algorithm also considers each qualifier as a class value as well,
which would be wrong here because resolution of LHS as a "value" happens
earlier in DoubleColonExpressionResolver and with slightly different rules. To
avoid that, do not mix in the "explicit receiver" scope tower processor when
creating processors for callable reference resolution.
Also delete unused functions and classes related to deleted scope, refactor
Scopes.kt
#KT-8596 Fixed
Try resolving the LHS only when it looks (PSI-wise) like it could represent a
type element. This, for example, allows "illegal selector" error to be reported
on weird expressions like '""?.""::class'.
Also remove expression text from the "illegal selector" diagnostic, it's not
needed and can screw up the error message if the text is too big
This is a radical but likely temporary measure to forbid the current compiler
from compiling code against binaries compiled by newer compilers
Cherry picked from commit 149a4eddff0106bbe91c9a6b51a26c12c242d14f and commit
285b20e3ff387eb3d2ee33ceaa376ed8eba90857
It's needed when declarations are parsed as a part of previous expression
(see tests)
Currently we apply this kind of recovery in a conservative way,
only when declaration starts at the next line, and while
the condition could be relaxed, there's no need to do this
#KT-4948 Fixed
#KT-7118 Fixed
Otherwise linenumber for previous instruction will be used in debugger. That can lead to error stepping
because it might be line that isn't reachable on current iteration.
#KT-13059 Fixed
Do not treat var as alive just because current instruction belongs to an item range
in local variables table, but the item has different sort of type
As liveness analysis is mostly used in coroutines spilling,
not applying this change may lead that to problems on Android (see tests)
If property name is parsed on the next line and declaration is invalid
(no receiver/type/initializer), treat that name as it does not belong to property
#KT-12987 In Progress
This test checks that the correct LanguageFeatureSettings instance (not
LanguageVersion.LATEST) is being passed to
createContainerForLazyLocalClassifierAnalyzer
Mikhail Glukhikh