1) Optimize and refactored code
2) Added support for correct renaming of target identifier to this/it
3) Added support of cases with difficult application targets (like: var x = 1 + 2)
4) Show error hint when refactoring failed for some reason
5) Improved intention applicability checking to eliminate false-positive cases
6) Fixed EA-209577
Now, call 'configureDefaultCheckers' and 'configureExtensionsAndCheckers'
from all childs configurators, instead of taking just container from
CommonPlatformAnalyzerServices
This is needed because some IDE services tend to re-create containers
(in particular, PerFileAnalysisCache and ResolveElementCache do that to
re-inject new trace) and use usual injection DSL, which, in particular,
takes 'platformSpecificContainer'.
Returning 'common'-conatiner leads to losing all platform-specific checkers.
On the other hand, calling exactly 'configureDefaultCheckers' +
'configureExtensionsAndCheckers' should be correct, because that's how
single-platform 'platformSpecificContainer' is composed (see
PlatformConfiguratorBase), and in 'createContainerForCompositePlatform'
we don't use 'platformSpecificContainer' anyways
^KT-23305 Fixed
previously for instance `KtClassBody` could get here as `leaf` and `leaf.parent` will return `KtClass` for it, making gutter for `KtClass` appear twice if origingal identifier and `KtClassBody` got here in different passes (one in "inner" other in "outer")
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.
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.
Dmitry Gridin