Hi, my name is JeanHeyd Meneide. I'm the Project Editor for C, but more importantly I'm the author of this paper: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2728.htm

Just a tiny comment: could you please make sure the name of the resolved encoding is also propagated to InitPreprocessor.cpp that sets the __clang_literal_encoding__ macro? (https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/InitPreprocessor.cpp#L784)

I actually think it's fine to just do == 8. I was just adding my comments for the benefit of the future, really! Doing a full -fwide-exec-charset= patch is definitely overkill for a simple case like this. I also just know there are a LOT of 8-bit character sets, so assuming UTF-8 might be a bit bad. But, again, you should definitely go ahead with >= 16 as the 2nd check and then leave the 8-bit case as last in the if-else chain:

In rG701d70d4c25c4e02b303ba6dee1495708496f615#990681, @ThePhD wrote:

In rG701d70d4c25c4e02b303ba6dee1495708496f615#990678, @nigelp-xmos wrote:

The XCore target has 8-bit wchar_t (unsigned char). Should there be a test for width == 8 and set to "UTF-8", or at least not "UTF-16"?

That's definitely news to me! If you can find a reliable way to set the encoding to "UTF-8" (like checking for XCore definitions or something) that could probably be added. Do you know a good way to identify an XCore machine? Is there a specific preprocessor builtin or option that correlates to XCore I can check in the code?

In rG701d70d4c25c4e02b303ba6dee1495708496f615#990678, @nigelp-xmos wrote:

The XCore target has 8-bit wchar_t (unsigned char). Should there be a test for width == 8 and set to "UTF-8", or at least not "UTF-16"?

In D100346#2686342, @aaron.ballman wrote:

Okay, I'm sold. Thank you for the detailed explanation! The changes LGTM. Do you have commit privileges or would you like me to commit on your behalf? (If you'd like me to commit, what email address and name would you like me to use for commit attribution?)

Oops, almost forgot the doc fixes for the *wide__* macro!

In D100346#2685530, @aaron.ballman wrote:

...

What about for folks using this from C where there isn't constexpr functionality to help them?

Update the text for the documentation to be more explicit.

In D100346#2684705, @rsmith wrote:

Exposing this information seems fine to me. I think it'd be more useful to expose it in a way the preprocessor can inspect ...

The tests check for macros in strict byte-value "alphabetical" order. We also need documentation, as was suggested!!

Fixes formatting derps in the pre-linter check.

Minor addition for this change; if this does go through, llvm-specific macros in C-like languages should expose the chosen name. I submitted a patch and a feature request to MSVC and GCC for their own implementation-specific macros as well: