Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
This commit fixes test infrastructure issue.
Usage of "COMPILER_ARGUMENTS" test-data-instruction resulted in side
effect. Test cases following the one that used it got broken
LanguageVersionSetting - LanguageFeature.MultiPlatformProjects escaped,
languageVersion could be wrong.
Why it happened
KotlinProjectDescriptorWithFacet defines default values
of (language-version, isMultiplatform) settings for the test-case.
The values themselves are stored in KotlinFacetSettings and passed there
only once. After every test-case (if it uses "COMPILER_ARGUMENTS")
infrastructure calls
KotlinLightCodeInsightFixtureTestCaseKt#rollbackCompilerOptions which
resets mentioned values (among others) in KotlinFacetSettings.
Instances of KotlinProjectDescriptorWithFacet are reused hence facet
settings remained reset.
annotation, data, enum, inner, open - classes supplied with these
modifiers cannot be sealed.
Commit fixes code completion - "sealed" is no longer suggested in
the mentioned case.
Property consists of getter and setter (both optional). The setter
have a single `value` parameter with type
Because of it, we have to make a separate 'frankenstein setter' with
original resolved header, but with the body of the fake one
It seems that getters does not have such issues
In such expressions, `KtCallExpression` wraps `KtSimpleNameExpression`,
so `getQualifiedExpressionForSelector()` returns `null`
Also, enable tests that are fixed by this
Generic candidate extensions are completed in partial mode
when there is not enough information for type parameter in return position.
Partial completion mode in single candidate resolver leads to unconditionally failing candidate.
Providing noExpectedType instead of null guarantees full completion.
Vladimir Dolzhenko