- get rid of obsolete interfaces and annotations
- rename actual resolver interface to ScriptDependenciesResolver
- make ScriptDependenciesResolverEx interface compatible with the one from 1.1-M01 to be able to support both on the provider side
- add possibility to override file patter in the script template provider
- construct resolver lazily, if possible
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
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
Previously the code was operating under the assumption that if the
implementation of some function (both the implementation and the function come
from supertypes) does not have a proper return type (the one which is a subtype
of return type of all declarations of this function in the supertypes), then
there's necessarily at least one abstract declaration of the function, such
that the implementation's return type is not a subtype of the return type of
that declaration. The assertion makes sense when the hierarchy above the
current class does not have any errors: we should report at least one function
as being "not implemented" in the current class.
However, as demonstrated by the test case, if there's an error already in the
supertypes with regard to overridability of members, this assertion may be
wrong. Reporting the "not implemented" error in such case is in fact not
necessary because of the already existing error ("return type mismatch" in the
test) in the supertypes
#KT-12482 Fixed
Ilya Chernikov