r184005 - Suppress the c++11 -Wdeprecated warning for 'register' ifit is expanded from a

Andy Gibbs andyg1001 at hotmail.co.uk
Sun Jun 16 10:00:30 PDT 2013


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)
 




More information about the cfe-commits mailing list