aaron.ballman added a comment. In D106577#2904724 <https://reviews.llvm.org/D106577#2904724>, @jyknight wrote:
> 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())`. This would work if it's necessary... > 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. I still don't fully understand the original comment from Joerg. The encoding of `L'a'` cannot change at runtime; it's a literal whose encoding is decided entirely at compile time. @joerg -- did you mean that Clang produces a different literal encoding depending on the environment the host compiler is running in? In D106577#2904960 <https://reviews.llvm.org/D106577#2904960>, @rsmith wrote: > I'd expect we will break at least things like libc++ tests that build with > `-Wsystem-headers` in the case where libc defines the macro. But if the > problem is limited to old libc and a rare use case, and can easily be worked > around with a `-Wno` flag, that's probably fine. Doesn't look to be in an old libc: https://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdc-predef.h;h=e130c462a7b71f87956a6d4b2bd69a38c9d9cb32;hb=refs/heads/master#l58 > One benefit we don't get with this approach is providing the right value for > the macro (without paying the cost of always including `stdc-predefs.h`). > AFAICS, the only possible use for the value of the macro is to detect libc > support, so having Clang pick a specific value seems wrong to me. In some > ways I'd be more comfortable with this patch if we defined the macro to `1` > and documented that we think WG14 was wrong to ask for a version number. Yeah, I'm hoping to hear what WG14 has to say on this. My original thinking was that this macro is used to tell users and libc what version of Unicode wchar_t literal values are encoded in (if any), but seeing that both glibc and musl (https://git.musl-libc.org/cgit/musl/tree/include/stdc-predef.h#n4) define this macro themselves, I am less certain. 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
