On Wed, Nov 30, 2022 at 12:17 AM Tom Honermann <tom_at_[hidden]> wrote:

> On 11/29/22 5:10 PM, Corentin Jabot wrote:
>
>
>
> On Tue, Nov 29, 2022 at 10:54 PM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
>> I think there is an issue with formatting of stacktrace for wide streams
>> as proposed in P2693R0. The paper proposes that formatting support be
>> provided as-if by an invocation of to_string for basic_stacktrace and
>> stacktrace_entry objects. However, to_string produces a std::string
>> which, I think (my grasp of the inner workings of std::format is not
>> strong), can't be formatted to a wide string (either directly or via the
>> format context). Likewise, there is no to_wstring overload defined for
>> basic_stacktrace and stacktrace_entry.
>>
>
> Yes, this is correct. There is no intent in our paper that format(L"",
> stacktrace); should work. It's all preexisting.
> You will notice that there is no formatter specialization proposed for
> wide strings.
>
> Thank you. It wasn't obvious to me that support for wide characters is not
> intended either in the proposal or in the existing wording for the ostream
> inserters. I find it odd that the ostream inserter declarations are
> specified for basic_ostream<charT, ...> but then specified such that charT
> !=char renders the program ill-formed. Why don't the declarations just
> require char? (I'm asking rhetorically).
>
It is (was) a bug https://cplusplus.github.io/LWG/lwg-defects.html#3515


>
> We (SG16) previously decided that the content of the stacktrace string is
> implementation-defined and we could devise scenarios such that they would
> involve multiple encodings within that string.
> So what is proposed matches that. wide encodings cannot be supported as
> immediately the question of "from what encoding do we convert" would have
> to be answered,
> and that would kind of force us to ask about the encoding of symbol names
> in the binary, which we never talked about before.
> We do not intend to ask, or answer these questions as part of this paper.
>
> Thanks, agreed, and I'm content with that.
>
> Tom.
>
>
> I don't think we should try to backdoor conversions from std::string to
>> std::wstring as part of resolving this. The simplest solution seems to
>> be to add to_wstring overloads for basic_stacktrace and stacktrace_entry
>> and then to modify the formatter specializations to use to_string or
>> to_wstring accordingly.
>>
>> Tangent: It looks like the operator<< overloads for basic_stacktrace and
>> stacktrace_entry probably don't work right for wide strings. They are
>> also defined in terms of to_string, but wide streams will convert for
>> charT==wchar_t, but do so via ctype<>::widen which doesn't work for
>> variable length encodings. Thus, identifiers for functions in the stack
>> trace may get mangled. I guess I should file a new LWG issue for this
>> assuming there isn't one already.
>>
> Tom.
>> On 11/29/22 3:40 PM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a telecon on Wednesday, November 30th, at 19:30 UTC (timezone
>> conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20221130T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>
>> ).
>>
>> *This message will also serve as your friendly reminder that this meeting
>> is taking place tomorrow. **I'm sorry for publishing an agenda so very
>> late. *
>>
>> *For participants in the USA, please note that daylight savings time
>> ended 2022-11-06, so this telecon will start one hour earlier than our last
>> telecon.*
>>
>> The agenda follows. We won't get through all of these. These are all of
>> the NB comments we have left to address. Whatever we don't get to in this
>> meeting will be scheduled for the December 14th meeting.
>>
>> - P2713R0: Escaping improvements in std::format
>> <https://wg21.link/p2713r0>
>> - US 38-098 22.14.6.4p1 [format.string.escaped] Escaping for
>> debugging and logging
>> <https://github.com/cplusplus/nbballot/issues/515>
>> - FR 005-134 22.14.6.4 [format.string.escaped] Aggressive escaping
>> <https://github.com/cplusplus/nbballot/issues/408>
>> - P2693R0: Formatting thread::id and stacktrace
>> <https://wg21.link/p2693r0>
>> - FR-008-011 22.14 [format] Support formatting of thread::id
>> <https://github.com/cplusplus/nbballot/issues/410>
>> - FR-010-133 [Bibliography] Unify references to Unicode
>> <https://github.com/cplusplus/nbballot/issues/412> and
>> FR-021-013 5.3p5.2 [lex.charset] Codepoint names in identifiers
>> <https://github.com/cplusplus/nbballot/issues/423>
>> - P2675R0: LWG3780: The Paper (format's width estimation is too
>> approximate and not forward compatible) <https://wg21.link/p2675r0>
>> - LWG #3780: format's width estimation is too approximate and not
>> forward compatible <https://cplusplus.github.io/LWG/issue3780>
>> - FR-007-012 22.14.2.2 [format.string.std] codepoints with width 2
>> <https://github.com/cplusplus/nbballot/issues/409>
>> - FR-020-014 5.3 [lex.charset] Replace "translation character set" by
>> "Unicode" <https://github.com/cplusplus/nbballot/issues/422>
>>
>> P2713R0 <https://wg21.link/p2713r0> (Escaping improvements in
>> std::format) implements the SG16 proposed resolutions for US 38-098
>> <https://github.com/cplusplus/nbballot/issues/515> (see the 2022-10-19
>> SG16 meeting summary
>> <https://github.com/sg16-unicode/sg16-meetings#october-19th-2022>) and FR
>> 005-134 <https://github.com/cplusplus/nbballot/issues/408> (see the 2022-11-02
>> SG16 meeting summary
>> <https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022>).
>> We'll review the wording and then poll forwarding to LEWG as the resolution
>> of the two NB comments.
>>
>> Candidate Poll 1: P2713R0: Forward to LEWG as the recommended resolution
>> of US 38-098 and FR 005-134 [amended to ...].
>>
>> P2693R0 <https://wg21.link/p2693r0> (Formatting thread::id and
>> stacktrace) is intended to resolve FR-008-011
>> <https://github.com/cplusplus/nbballot/issues/410>. I did not initially
>> tag this NB comment as needing SG16 review, but Bryce requested that SG16
>> take a look, specifically with regard to narrow vs wide formatting. Bryce
>> has indicated this paper will need to be approved soon in order for it to
>> appear in the electronic polling that will be conducted in January.
>>
>> Candidate Poll 2: P2693R0: Forward to LEWG as the recommended resolution
>> of FR-008-011 [amended to ...].
>>
>> FR-010-133 <https://github.com/cplusplus/nbballot/issues/412> and
>> FR-021-013 <https://github.com/cplusplus/nbballot/issues/423> were
>> discussed during the 2022-11-02 SG16 meeting
>> <https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022> and
>> concluded with a recommendation to discuss with the project editor the
>> possibility of preferring the Unicode Standard over ISO/IEC 10646 within
>> the C++ standard. The project editor approved this direction and we can now
>> move forward with drafting wording changes. This will require a paper
>> produced in short order if it is to be accepted for C++23.
>>
>> P2675R0 <https://wg21.link/p2675r0> (LWG3780: The Paper (format's width
>> estimation is too approximate and not forward compatible)) is intended to
>> resolve LWG #3780 <https://cplusplus.github.io/LWG/issue3780> and
>> FR-007-012 <https://github.com/cplusplus/nbballot/issues/409>. It seeks
>> to replace the explicit list of code point ranges in
>> [format.string.std]p12 <https://eel.is/c++draft/format.string.std#12>
>> with wording that derives substantially the same set of code points using
>> Unicode database properties.
>>
>> Candidate Poll 3.1: P2675R0: Forward to LEWG as the recommended
>> resolution of FR-007-012 [amended to ...].
>> Candidate Poll 3.2: P2675R0: Forward to LEWG for C++26 [amended to ...].
>> Candidate Poll 3.3: Recommend to LEWG that FR-007-012 be rejected.
>>
>> FR-020-014 <https://github.com/cplusplus/nbballot/issues/422> raises
>> concerns that were discussed as part of the reviews of P2314
>> <https://wg21.link/p2314> and P2297 <https://wg21.link/p2297> during the 2021-03-24
>> SG16 meeting
>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#march-24th-2021>.
>> The comment does not appear to present new information. If we choose to
>> accept, a paper will need to be quickly produced.
>>
>> Candidate poll 4.1: Recommend to CWG that FR-020-014 be accepted.
>> Candidate poll 4.2: Recommend to CWG that FR-020-014 be rejected.
>>
>> Tom.
>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>