Older kotlinc versions (1.1.5?) didn't generate the 'INNERCLASS' attribute for some anonymous classes, e.g. for 'crossinline' lambdas.
An example: 'Timer().schedule(1000) { foo () }'
Normally, stub loader checks if the class is 'ClassFileViewProvider.isInnerClass()', and ignores the class file.
Without the 'INNERCLASS' attribute this check fails. As the stub loaded isn't created to deal with anonymous classes nicely, it fails miserably.
This commit explicitly ignores classes with local visibility.
Before this commit, Kotlin evaluator used the precise value type for variable finding.
As a result, VariableFinder often failed to find such a variable (cause the real one has a super type).
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.
Yan Zhulanow