Properly implement warn_unused_result checking for classes/structs.

Aaron Ballman aaron at aaronballman.com
Thu Apr 2 07:20:15 PDT 2015


LGTM!

~Aaron

On Wed, Apr 1, 2015 at 7:30 PM, Kaelyn Takata <rikka at google.com> wrote:
> The previous implementation would copy the attribute from the class to
> functions that have the class as their return type when the functions
> are first declared. This proved to have two flaws:
>   1) if the class is forward-declared without the attribute and a
>      function or method with the class as a its return type is declared,
>      and afterward the class is defined with warn_unused_result, the
>      function or method would never inherit the attribute, and
>   2) the check simply failed for functions and methods that are part of
>      a template instantiation, regardless of whether the class with
>      warn_unused_result is part of a specific instantiation or part of
>      the template itself (presumably because those function/method
>      declaration does not hit the same code path as a non-template one
>      and so never inherits the attribute).
>
> The new approach is to instead modify the two places where a function or
> method call is checked for the warn_unused_result attribute on the decl
> by extending the checks to also look for the attribute on the decl's
> return type.
> </commit-message>
>
> I've unified the two locations that performed the check into a helper method
> of FunctionDecl that returns true if the decl or its return type have the
> warn_unused_result attribute, except if only the return type has the
> attribute and the decl is a member of the return type (which avoids spurious
> messages on e.g. assignment operators).
>
> Cheers,
> Kaelyn
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>



More information about the cfe-commits mailing list