Currently, it's impossible to call suspend functions in evaluated code fragments (see KT-31701).
This commit officially prohibits such calls, so users will see a semi-friendly error message.
Before this commit, line numbers were only available on 'when' clause bodies.
So, if a clause condition check didn't succeed, the entirely clause could be ignored.
Kotlin compiler strips all debug information for @InlineOnly functions, making them non-debuggable.
This commit disables breakpoints inside @InlineOnly functions to prevent false expectations.
"Simplify filter {}" conversion changes semantics when the casted type is not a subtype if an initial collection element type.
This commit limits a replacement suggestion to subtype cases.
Ensure that breakpoints of each type can be placed only on lines where it makes sense to place a breakpoint.
Here is a quick summary of the rules:
1. Method breakpoints are available for functions, property accessors, constructors;
2. Line breakpoints are available on any line with an expression, excluding some cases like 'const' property initializers or annotations;
3. Line breakpoints should be available on a '}' in functions and lambdas;
4. Line breakpoints are not suggested for one-liners;
5. Lambda breakpoints should be shown for single-line lambdas.
Now it's possible to put a function breakpoint.
In JVM, function breakpoints behave as JVM method breakpoints. Normally, they're triggered twice – once on enter, and once on exit.
The function was placed in a package whose another top-level function
used coroutines. This led to a NCDFE kotlin.coroutines.Continuation
with Gradle versions that bundle Kotlin pre-1.3 stdlib.
Instead, use the existing util function `lowerCamelCaseName` which also
filters nulls.
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
In the old JVM backend, JvmSerializationBindings are created per
ClassBuilder, and special care must be taken to make sure that
JVM-specific metadata ends up in the correct bindings. This is
especially relevant for declarations whose metadata is moved to other
classes away from the place where the original declaration lies, for
example properties moved from companion object to the outer class, or
synthetic methods for annotation properties in interfaces moved to
DefaultImpls, or const properties in multifile parts moved to the
facade.
In the JVM IR backend, this seems not necessary and actually it's
complicated to ensure that we use the correct ClassBuilder for bindings
(see the code simplification in ClassCodegen). Therefore, in case we
don't have an easy way to retrieve the correct ClassBuilder instance, we
now write all JVM-specific metadata to the new _global_ bindings map in
GenerationState, which is used by JvmSerializerExtension as a fallback
if the ClassBuilder's local map has no relevant key.
This is needed in order to support wrapped properties properly in
KotlinTypeMapper (see the `is PropertyAccessorDescriptor` call in
`mapFunctionName`) which is still being used when mapping function call
signatures
Replace iteration over all tasks with `.matching { ... }` with `
.configureEach { if (...) ... }`, so that the check iterates
just over those tasks which are triggered to configure from
somewhere else.
Issue #KT-31666 Fixed
Yan Zhulanow