[PATCH] avoid -Wnonnull for lambda stubs (PR c++/95984)

[Martin Sebor]

On 7/1/20 3:25 PM, Jason Merrill wrote:
> On 7/1/20 3:31 PM, Martin Sebor wrote:
>> The attached patch avoids null pointer checking for the first
>> argument to calls to the member operator() of lambda objects
>> emitted by the C++ front end.  This avoids both the spurious
>> -Wnonnull warnings for such calls as well as the ICE reported
>> in the bug.
>>
>> In addition, the patch also avoids function argument checking
>> for any calls when the tf_warning bit isn't set.  This isn't
>> strictly necessary to avoid the ICE but it seems like a good
>> precaution against something similar occurring in other checks
>> in the future(*).
>>
>> Finally, while testing the fix I noticed that the common code
>> doesn't recognize nullptr as a poiner when processing templates.
>> I've extended the handling to let it handle it as well.
> 
> Any possible value of nullptr_t is null, so I think ignoring it is 
> appropriate.

In ordinary (including variadic) functions, GCC warns for all
null pointers, including nullptr.  In templates (and in auto
arguments), GCC warns for nullptr only when its converted to
a pointer type (e.g., (void*)nullptr) but not for naked nullptr.
As a user, I expect a warning for all null pointers in all these
contexts.  The distinction between the two kinds is too subtle
to appreciate by most of us (or to be useful in this context).
The test case below (I put it together to verify my patch was
working) shows the difference with lambdas:

   template <class L> void f (L f) {
     f ((void*)nullptr);   // -Wnonnull
   }

   template <class L> void g (L f) {
     f (nullptr);          // missing -Wnonnull
   }

   void h ()
   {
     f ([](auto...) __attribute__ ((nonnull)) { });
     g ([](auto...) __attribute__ ((nonnull)) { });
   }

> 
>> [*] It seems to me that a more robust solution to prevent
>> the diagnostic subsystem from being re-entered as a result
>> of callbacks into the front end would be to have the pretty
>> printer disable all warnings prior to the bcallbacks and
>> re-enable them afterwards.  That would require an efficient
>> and reliable way of controlling all warnings (as well as
>> querying their state), which I think would be a useful
>> feature to have in any case.  For one thing, it would make
>> handling warnings and responding to #pragma GCC diagnostics
>> more robust.
> 
>> +          const char *arg0str = IDENTIFIER_POINTER (arg0name);
>> +          closure = !strcmp (arg0str, "__closure");
> 
> Let's use id_equal here.

Done in the attached revision.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-95984.diff
Type: text/x-patch
Size: 4445 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200702/288a9f90/attachment.bin>