We don't want to deprecate freezing at all, but it is possible
that freezing, new memory model and lazy global initialization
combination might not work in some cases. It might be a problem
when such case appears in 3rd-party library that user can't fix.
To mitigate this problem this commit introduces `freezing` binary
option. It has three variants:
* Full - ol' good behavior.
* Disabled - well, no freezing at all.
* ExplicitOnly - a compromise when user want to freeze something
themselves, but something is messed up during globals initialization.
We need a handle that allows user to pick `dev` variant instead of
`user` one just in case.
Additionally, I added a possibility to provide a path to an arbitrary
LLVM distribution because it is useful for development purposes.
^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.
Dmitriy Dolovov