[clang] [llvm] Enable fexec-charset option (PR #138895)

[Sergei Barannikov via llvm-commits]

s-barannikov wrote:

> Since I removed the "system encoding" references from my PR, in summary, we think typeinfo name should be in a consistent codepage (UTF-8) for non-zOS platforms. This is because typeinfo is a global class and would require a consistent codepage in order to do comparisons, even in the case where the fexec-charset is different. Another reason another reviewer pointed out previously is that the string is often used in printf/demangler which would expect a UTF-8 string literal.

Sorry, I don't understand this still. I can say this about any other string literal. E.g., "Hello, %f!\n" should be encoded in UTF-8 because it may be passed to a library compiled with a different `-fexec-charset` option. That library may use `str[0] == 'H'` and thus 'H' should also be encoded as UTF-8 so that we can handle UTF-8-encoded "Hello, world!\n" correctly. We may also want to pass the string to `printf` compiled with yet another `-fexec-charset` option, and thus the libc implementation should also use UTF-8 for encoding '%' and for everything else. This basically means that `-fexec-charset` option has no effect at all.

I'll summarize my thoughts:
* typeinfo name is no different from any other (compiler-generated or not) string literal and should be encoded as such. That is, respecting `-fexec-charset` option.
* Using `-fexec-charset` when compiling a single source file "poisons" it. A file compiled with a non-default value of the option may only be linked with other files/libraries compiled with the same value of the option. This includes all user libraries, compiler libraries such as libc++/abi, and system libraries (including libc). Same requirements as using `-fshort-wchar` or `-fshort-enum`, which also change the ABI (but in a more obvious way). If I understand correctly, this will work best on localized Windows versions that still use country-local code pages for narrow string literals.
* I realize this may be problematic/inconvenient to use in practice, and we need to give users more flexibility and/or protect them from shooting their own leg by mixing libraries compiled with different `-fexec-charset` options, be it `-fzos-le-char-mode`, replicating typeinfo names in two encodings or something else. I suspect z/OS will be the only user of this functionality.

> Since I removed the "system encoding" references from my PR

I may have missed it and will take another look.


https://github.com/llvm/llvm-project/pull/138895