On Sunday, June 16, 2013 6:40 PM, David Blaikie wrote:
On Sun, Jun 16, 2013 at 9:15 AM, Andy Gibbs wrote:
On Friday, June 14, 2013 11:05 PM, Richard Smith wrote:
Author: rsmith
Date: Fri Jun 14 16:05:24 2013
New Revision: 184005
URL: http://llvm.org/viewvc/llvm-project?rev=184005&view=rev
Log:
Suppress the c++11 -Wdeprecated warning for 'register' if it is expanded
from a
macro defined in a system header. glibc uses it in macros, apparently.
Not just glibc, I'm afraid. Here's the output from using python headers:
In file included from /usr/include/python2.7/Python.h:94:
/usr/include/python2.7/stringobject.h:173:5: warning: 'register' storage
class specifier is deprecated [-Wdeprecated]
register PyObject *obj, /* string or Unicode object */
^~~~~~~~~
/usr/include/python2.7/stringobject.h:174:5: warning: 'register' storage
class specifier is deprecated [-Wdeprecated]
register char **s, /* pointer to buffer variable */
^~~~~~~~~
/usr/include/python2.7/stringobject.h:175:5: warning: 'register' storage
class specifier is deprecated [-Wdeprecated]
register Py_ssize_t *len /* pointer to length variable or NULL
^~~~~~~~~
I expect it is unreasonable to ask for all "system" headers to be exempt
(which would be nice!), so as an alternative suggestion, can the warning
group be changed to something more specific, e.g. -Wdeprecated-register,
so
that it can be disabled without having to disable the whole -Wdeprecated
warning? Unfortunately, deprecating "register" while laudable in the
long-term breaks things in the short term like gcc's deprecation of
std::auto_ptr did for many people. It would be nice to have an easier
upgrade path for all those projects compiled -Werror.
Given that I assume we don't actually respect the 'register' keyword
at all (it's only a hint, not a guarantee, so far as I know) I assume
it would OK to provide fixit hint that just suggests removing the
'register' keyword. That would make for a fairly easy upgrade - simply
running clang in -fixit mode.
While this is certainly good, it is the system headers that "cannot be
edited" (easily) that are the problem.
(though, yes, I think most of these deprecations probably need a
separate flag since they'll each need to be assessed & addressed
separately in a given codebase)
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
