Subject: Re: Clang RFC: Enabling fexec-charset support to LLVM and clang
From: Tom Honermann (tom_at_[hidden])
Date: 2020-12-14 10:54:03
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.
>> 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.
> 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).
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.
SG16 list run by firstname.lastname@example.org