^KT-44626
Typical use case:
- There are two KLIB libraries: A and B.
- Library A has two versions: A.v1 (older) and A.v2 (newer).
- A.v2 is ABI-incompatible with A.v1.
- B depends on A and was compiled against A.v1.
- An attempt to build the application with A.v2 and B fails with weird error message. It's unclear for end user what's wrong and what needs to be done to fix the issue.
The fix improves error reporting for the following particular cases:
- A symbol that is gone (KT-41378)
- A class that became a typealias (KT-47285, KT-46697)
- A typealias that became a class (KT-46340)
* Do not reset unhandled exception hook
* Add processUnhandledException to perform default unhandled exception
processing
* Add terminateWithUnhandledException to report the unhandled exception
and terminate the program
* Use the default unhandled exception processing in entrypoint, interop
boundaries and in Worker.executeAfter
* Add -Xworker-exception-handling to control exception processing of
Worker.executeAfter. By default its the old behaviour with the old MM,
and new behaviour with the new MM.
Clang-produced and GCC-produced binaries might be ABI-incompatible on
MinGW. Explanation on GitHub: msys2/MINGW-packages/issues/6855#issuecomment-680859662.
TL;DR: GCC-generated sections are 16-byte-padded, while Clang ones are
not. It causes problems during merge of COMDAT sections.
I observed the problem during compilation of runtime tests, but it is
possible that the problem could affect main compilation pipeline as well.
https://reviews.llvm.org/D86659 (which landed in LLVM 12) fixes
the problem. So we have another motivation for switching to LLD besides
https://youtrack.jetbrains.com/issue/KT-47605.
The only known downside is unsupported defsym which causes slight binary
size increase. I think it is doable.
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
### What's done:
- Fixed incorrect logic of String.toFloat() and String.toDouble().
Long string without any digits were treated as Float or Double:
"this string does not look as float isn't it?".toFloat() == "Infinity".
- Fixed incorrect parsing of floating point constants "NaN" and "Infinity":
String values like "NaNPICEZy" or "InfinityN" were treated as valid numbers.
- Merged parsing logic for Double and Float:
Removed the code duplication, unified methods, made the code more Kotlin-like, not C++-like.
- Updated tests:
Removed useless tests that checked nothing, updated tests with regression scenarios.
Dmitriy Dolovov