On 18/05/18 11:58 -0400, Jason Merrill wrote:
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.
Right. std::exception has no data members anyway, so moving is the
same as copying. For the derived types the standard declares them
like:
namespace std {
class logic_error : public exception {
public:
explicit logic_error(const string& what_arg);
explicit logic_error(const char* what_arg);
};
}
But we define:
class logic_error : public exception
{
[...]
virtual ~logic_error() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_USE_NOEXCEPT;
[...]
};
And this means there is no move constructor or move assignment operator.
