On 15/09/2015 23:57, Jonathan Wakely wrote:
> On 14/09/15 20:26 +0200, François Dumont wrote:
>> On 08/09/2015 22:47, François Dumont wrote:
>>> On 07/09/2015 13:03, Jonathan Wakely wrote:
>>>> On 05/09/15 22:53 +0200, François Dumont wrote:
>>>>> I remember Paolo saying once that we were not guarantiing any abi
>>>>> compatibility for debug mode. I haven't found any section for
>>>>> unversioned symbols in gnu.ver so I simply uncomment the global
>>>>> export.
>>>> There is no section, because all exported symbols are versioned.
>>>>
>>>> It's OK if objects compiled with Debug Mode using one version of GCC
>>>> don't link to objects compiled with Debug Mode using a different
>>>> version of GCC, but you can't change the exported symbols in the DSO.
>>>>
>>>>
>>>> Your changelog doesn't include the changes to config/abi/pre/gnu.ver,
>>>> but those changes are not OK anyway, they fail the abi-check:
>>>>
>>>> FAIL: libstdc++-abi/abi_check
>>>>
>>>> === libstdc++ Summary ===
>>>>
>>>> # of unexpected failures 1
>>>>
>>>>
>>> Sorry, I though policy regarding debug mode symbols was even more
>>> relax.
>>> It is not so here is another patch that doesn"t break abi checks.
>>>
>>> I eventually made all methods that should not be used deprecated, they
>>> were normally not used explicitely anyway. Their implementation is now
>>> empty. I just needed to add a symbol for the not const _M_message
>>> method
>>> which is the correct signature.
>>>
>>> François
>>>
>> I eventually considered doing it without impacting exported symbols. I
>> just kept the const qualifier on _M_messages and introduced a const_cast
>> in the implementation.
>>
>> Is it ok to commit with this version ?
>
> The changes look OK now (assuming it passes 'make check-abi') but what
> does it actually do?
Mostly clean code, I have been upset in the past to be forced to
introduce new print methods to _Error_formatter or _Parameter type while
those methods were only used through a call to _M_error. Now we can
change anything to the code used to output the diagnostic without having
to also impact _Error_formatter.
I also disliked the mutable fields of _Error_formatter, it often
indicates a design flow, which was the case here.
>
> Does it significantly improve the output?
Not significantly. I initially start working on that because debug
messages were wrapped is a bad way. The message used to be cut on any
character that was not alnum, now we cut only on space. I would like to
improve rendering of types, they are not respecting the max line length
that can be specified by users, but that's not top priority of course.
Committed.
François
