Kotlin's function literals have a shortcut for one-argument literals:
the single argument doesn't need to be explicitly named, but can be
referred via the 'it' contextual keyword. Add an intention action for
converting an implicit 'it' parameter to an explicitly named one.
For example, 'array(1, 2, 3).filter { it % 2 == 0 }'
-> 'array(1, 2, 3).filter { x -> x % 2 == 0 }'
Kotlin's function literals have a shortcut for one-argument literals:
the single argument doesn't need to be explicitly named, but can be
referred via the 'it' contextual keyword.
For example, 'array(1, 2, 3).filter { x -> x % 2 == 0 }'
-> 'array(1, 2, 3).filter { it % 2 == 0 }'
Add an intention action for this transformation.
Use reflection in ProgressionUtilTest instead of calling methods on the class
from the class path, because in the latter case we were just testing
ProgressionUtil from bootstrap runtime (which, presumably, always works
correctly since it's a bootstrap distribution)
With this change, compilable built-ins (under core/builtins/src) are fully
written in Kotlin
Add tests for JetRefactoringUtil.selectExpression, which is invoked by
e.g. extract variable when some text is selected.
Test cases under idea/testData/expressionSelection/ should contain
Kotlin files with the usual <selection> tags, with the expected result
of selectExpression in the last comment of the file.
The basic principle behind this change is that no context object should store components.
Components should be injected instead, and contexts only carry parameters around.
Particular changes:
- resolveCallWithGivenName() and resolveBinaryCall() moved to CallResolver
- ForLoopConventionsChecker introduced to confine checking conventions for Iterator and Iterable
- ExpressionTypingComponents introduced to deliver necessary components to ExpressionTypingVisitor's
- Some static methods became non-static to get access to injected components
- ExpressionTypingUtils and ControlStructureTypingUtils became components (got state injected) to avoid passing parameters around
Float.rangeTo(Long) and Long.rangeTo(Float) now both return FloatRange for
consistency with other binary operations between floats and longs which, in
turn, return float to be consistent with Java
This keeps behaviour consistent in rare cases when JavaClass can be found but not resolved
As of now this can happen in IDE if we take PsiClass from index but file structure is wrong so we can't resolve the class
Add test which documents this case
Remove LazyJavaClassResolverWithCache
This actually can affect behaviour because JavaResolverCache has slightly different logic (uses CLASS key in BindingContext as opposed to FQNAME_TO_CLASS_DESCRIPTOR)
Add test suite for smart expression selector (the small expression list
popup in e.g. Extract Variable.)
The test file format is similar to that in JetNameSuggesterTest: a .kt
file with the usual <caret> marker specifying the place where the smart
selector will be run. Then, the last comment in the file should contain
the expected outcome.
gavinkeusch