If a certain type statement is true on loop entry and all continue
paths, then it is also true on exit if the condition did not reassign
the variable.
^KT-7676 tag fixed-in-k2
It's also not a backwards jump in do-while, unless it's in the loop's
condition, which is a stupid "feature" IMO. As you can probably tell
from the comments added in this commit.
Because in kapt stub generation mode (aka ClassBuilderMode.KAPT3, aka
generateBodies=false in psi2ir), method bodies are not generated and
compiler plugins such as kotlinx-serialization might not expect that.
#KT-54245 Fixed
This should prevent issues when ascii characters are uppercased or
lowercased on users machines with their locales.
For example in Turkish locale:
* 'i' uppercases to 'İ'
* 'I' lowercases to 'ı'
^KT-38712 Verification Pending
In some cases where the Kotlin compiler encounters an exception, it attempts to print the contents of the file that it was compiling at the time. Sometimes the content contains symbols that aren't bound to implementations. When that happens the safe value parameters for a function are empty because none of them can be resolved, but the value parameter count is still non-zero because the function reference still has multiple params — this causes exception messages to fail with an error:
```
Exception in thread "main" java.lang.IllegalStateException: Problem with constructing exception message
```
This fixes the issue by only attempting to access the safe value parameters if the list is of the proper size.
KT-54012
- `context(...)` is a modifier that must precede annotations and other
modifiers, so for declarations it is rendered in
`renderAnnotationsAndModifiers`.
- Ignore `@ContextFunctionTypeParams` in the annotation list of FE10
types, as the annotation is an implementation detail of context
receivers in K1 and shouldn't be rendered.
^KT-55098 fixed
- Context receivers in function types may not be labeled, so the created
`KtContextReceiver`s have `null` labels. Such labels currently only
compile due to a bug (see KT-55187).
xcodebuild -version call may take enormous amount of time even after warmup. To alleviate this, first try to check Xcode version directly by reading application .plist file, but still use xcodebuild -version as a fallback.
Merge-request: KT-MR-7694
Merged-by: Gleb Lukianets <Gleb.Lukianets@jetbrains.com>
pyos