jyknight added a comment. Perhaps a reasonable path forward here to address the BSD issue can be to add a targetinfo method:
/* Returns true if the expected encoding of wchar_t changes at runtime depending on locale for this target. Note that clang always encodes wide character literals as utf16/utf32, regardless. */ bool usesDynamicWCharEncoding(); which returns false by default, and true for FreeBSD, NetBSD, OpenBSD, and Solaris. Then, the condition for setting this define can be `if(TI.getWCharWidth() >= 32 && !TI.usesDynamicWcharEncoding())`. That doesn't help the fact that wide char literals are effectively broken on those OSes, but oh well. Maybe someday they'll decide to switch to a consistent/documented wchar encoding, at which point clang can emit that (whatever it is). Or maybe someone will teach clang to emit an error or warning when using wide char literals on such targets. But I wouldn't hold my breath for either of those outcomes, and it seems fine to move forward here simply by exempting the known-to-be-problematic OSes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106577/new/ https://reviews.llvm.org/D106577 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits