On Sun, Jun 16, 2013 at 9:15 AM, Andy Gibbs <[email protected]> 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. (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) > > Cheers, > > Andy > > > > > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
