We've found that the BindingContext is necessary for any meaningful suppressor.
This change adds the ability for suppressors to use the BindingContext when available.
Change-Id: I14d8148ef659eca273445bf0638bcdb8c3b21f02
When using dummy resolving for creating stubs of data classes we do not have overriding information
which is needed to determine whether we need to generate synthetic members or not.
As a result of that, we may have two different versions of member scope: the first one is
resolved by dummy resolving and the second one resolved via an ordinary one.
As light methods depend on the index of them in the class body,
we can have two different methods with the same index
which breaks mapping from dummy resolved methods to normal ones.
This behaviour can be reproduced when having data class which
extends other class with some synthetic members overridden and marked as final
like described in #KT-32969
#KT-32969 fixed
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.
Steven Schäfer