On 12/10/20 5:30 PM, Jens Maurer via SG16 wrote:
> On 10/12/2020 15.50, Tom Honermann via SG16 wrote:
>> An RFC has been posted to the Clang developer mailing list discussing
>> support for the -fexec-charset option.
>>
>> http://lists.llvm.org/pipermail/cfe-dev/2020-December/067354.html
>>
>> Jens, the RFC has a nice break down of places where string literals
>> appear and what the conversion requirements are for them. It might be
>> useful input to your planned paper that we discussed in yesterday's SG16
>> telecon with regard to what phase of translation those conversions occur in.
> Thanks.
>
> The list is missing static_assert.
>
> Also, the typeinfo name should probably use the literal encoding.
> (More often than not, it is displayed.)

Good points. I replied to the initial thread (though I clearly should
have responded in text format).
- http://lists.llvm.org/pipermail/cfe-dev/2020-December/067368.html

My contribution was:

> The text provided by std::type_info::name() is generally displayed in
> some way, often in conjunction with additional text encoded with the
> execution encoding. I think this should follow -fexec-charset; that
> would be consistent with handling of __func__.
>
> The messages provided for #error, static_assert, [[deprecated]], and
> [[nodiscard]] (following adoption of WG14 N2448
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2448.pdf> and WG21
> P1301 <https://wg21.link/p1301>) are another special case. Options
> are to preserve the provided message in the internal encoding or, as
> mentioned below, to transcode from the execution encoding to the
> system encoding for diagnostic display. Per WG14 N2563
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2563.pdf> and WG21
> P2246 <https://wg21.link/p2246>, either approach is acceptable, but
> the former would improve QoI.
Tom.

>
> Jens
>
>