The problem was that for property getter 'context.getContextDescriptor()'
references the containing property, while 'context.getFunctionDescriptor()'
the accessor itself
#KT-15594 Fixed
The main problem here is that moduleName that is being passed to KPackageImpl
is useless: as can be seen in
ClosureCodegen.generateCallableReferenceDeclarationContainer, the name of the
current module is always written to the class file for a callable reference,
not the name of the module of the referenced declaration. This resulted in
reflection not loading the correct .kotlin_module file and subsequently not
finding the required file facade for a top-level function.
The commit does not fix the issue with the incorrect module name written in the
back-end, but workarounds it. It turns out, reflection can figure out the name
of the module of the referenced declaration itself by parsing the header from
the given java.lang.Class object for a single-file/multi-file package facade
and extract the package_module_name protobuf extension. Similar code was
already there in Member.getKPackage() in ReflectJvmMapping.kt but it did not
support multi-file classes, of which there are a lot in the standard library;
this is now supported
#KT-12630 Fixed
#KT-14731 Fixed
A lot of problem arise with current solution
(loading them with lowpriority annotation + additional call checkers):
- We errorneously treated ArrayList.stream as an existing method, while
it's just a fake override from List
- The same problem arises when creating a class delegating to List.
Also the latter case is failing with codegen internal error
(see issue KT-16171)
The negative side of this solution is that instead of reporting meaningful
diagnostic, there will be UNRESOLVED_REFERENCE.
But it seems to be better than having strange problems like ones described above.
#KT-16073 Fixed
#KT-16171 Fixed
Previous version of the boxing/unboxing analysis treated merging boxed and non-boxed values as a hazard.
If such merged values are not used (e.g., early return + local variables reused in inlined calls),
corresponding boxing/unboxing operations still can be optimized out.
All information related to boxed value usage by instructions is moved to 'BoxedValueDescriptor'.
Introduce "tainted" (and "clean") boxed values, with the following rules:
merge(B, B) = B, if unboxed types are compatible,
T, otherwise
merge(B, X) = T
merge(T, X) = T
where
X is a non-boxed value,
B is a "clean" boxed value,
T is a "tainted" boxed value.
Postpone decision about value merge hazards until a "tainted" value is used.
Since annotations are a part of the declaration, they must have the same
visibility as the declaration in the bytecode. Otherwise obfuscators like
Proguard might strip the "$annotations" method and no annotations would be
found via Kotlin reflection
#KT-15993 Fixed
While within a method by the JVM spec null-value has a special
Nothing-like type, when we spill it for a coroutine, we must choose
some real type to CHECKCAST to after restoring the variable's value.
But the problem is that such a real type depends on usage of that null value,
and there may be more than one usage.
The solution is not to spill such variables into fields, but instead
init them with ACONST_NULL after each suspension point
#KT-16122 Fixed
The main problem is that inside a state machine for a named suspend
function parameters of it's owner are available as a usual captured
closure parameters (i.e. through synthetic fields), while
TailRecursion codegen expects that parameters are straight local
variables.
So, the solution is just to define local var for each of real parameters
(all but the last continuation parameters) for tailrec functions.
#KT-15759 Fixed
Array instatiation code should handle type alias constructors properly.
So far, we don't have constructors with type parameters
different from the type parameters of the resulting type,
so we can safely take type arguments of the underlying type.
The problem was that we spilled the `origin` variable (see test) as Object, because
we determined the type of merge(null, String) incorrectly.
#KT-15973 Fixed
Also move internal declarations from runtime.jvm module into new package
kotlin.coroutines.jvm.internal in stdlib
The necessity of these declarations being in built-ins is controversial,
but also it will complicate the migration of current coroutine runtime
to a separate jar if we ever need this
Suspend function call with a reachable (alive) begin marker and unreachable (dead) end marker
is an exit point for the corresponding coroutine.
It isn't a suspension point, and doesn't introduce a new state in the coroutine FSM.
Denis Zharkov