On Fri, May 18, 2018 at 11:55 AM, Jason Merrill <ja...@redhat.com> wrote:
> On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
>> On 18/05/18 10:29 -0400, Jason Merrill wrote:
>>>
>>> The second patch is some libstdc++ changes to avoid warnings from uses
>>> of the standard library when this warning is on. More are almost
>>> certainly needed. Jonathan, how would you like me to handle this WRT
>>> the library? Check in both patches and let you follow up as needed?
>>
>>
>> Yes, please go ahead and commit the library patch, we'll deal with the
>> rest as needed (I'll give myself a TODO to test with -Wdeprecated-copy
>> and fix what I find).
>>
>> I'm not sure we need the "Avoid implicit deprecation" comments. Adding
>> defaulted definitions is good style anyway, so needs no justification.
>> I'll make sure nobody removes them again in the name of cleaning up
>> unnecessary noise (which they aren't).
>
> OK.
>
>> Did you change your mind about leaving the exception hierarchy without
>> the defaulted ops, to get warnings for slicing?
>
> Yes, because the warning also triggers in cases where we know the
> dynamic type of the object, such as
>
> exception e;
> throw e;
>
> I think a slicing warning should be separate.
>
> Also because these functions are required by the standard, as below.
>
>> I've just realised that our user-declared destructors on the exception
>> classes (which exist so we can control where the key function is
>> emitted) mean they have no implicit move ops. But the standard implies
>> they should have implicitly-declared move ops (because it doesn't
>> declare any special members for those classes). I'll open a bug.
>
> Hmm, looks to me like it declares special members.
>
> 21.8.2 Class exception [exception]
>
> namespace std {
> class exception {
> public:
> exception() noexcept;
> exception(const exception&) noexcept;
> exception& operator=(const exception&) noexcept;
> virtual ~exception();
> virtual const char* what() const noexcept;
> };
> }
...though this is not true of many of the derived exception classes.
Jason
