[PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

[Richard Smith]

On Tue, Jul 16, 2013 at 10:45 AM, David Blaikie <dblaikie at gmail.com> wrote:

> I know we'd previously discussed the idea of being able to warn about
> unused variables of non-trivial types - you'd gone so far as to
> suggest the idea of a positive attribute (annotate the classes that
> have side effects, rather than those that don't, since the former
> seems like the exception rather than the rule).
>

Right. We usually try to stay on the side of no-false-positives, but in
this case diligent users would find themselves annotating nearly all
classes, and that doesn't seem like a good tradeoff. Also, we identified
that there are at least three different kinds of class here:

 1) Those where the ctor and/or the dtor has external, permanent
side-effects (probably very rare)
 2) Those where the ctor or dtor have external, temporary side-effects, but
running one then the other is essentially equivalent to running neither
(for instance, many RAII objects follow this pattern)
 3) Those where the ctor and dtor have no external side-effects

Consider:

{
  my_lock(my_mutex); // A
  my_lock ml(my_mutex); // B
  my_string("foo"); // C
  my_string ms("foo"); // D
}

We never warn for a class that is in category (1). my_lock would be in
category (2), so we warn on A but not B. my_string would be in category
(3), so we warn on both C and D.

Which of these does the warn_unused attribute model?

I don't suppose that is sufficiently related to this to warrant any
> changes here (we probably want to support this the way GCC does for
> compatibility at least, even if we come up with a more advanced scheme
> (positive annotations & describing the difference between a full-side
> effect (such as printing call start/end) and scope (like locks -
> warning when there's no code between construction and destruction))).


Yeah, if GCC's warning proves valuable, we might want to implement it
warts-and-all (to assist people using both compilers), even if we also want
to add something better.

On Tue, Jul 16, 2013 at 5:20 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
> > LGTM.
> >
> > On 16 July 2013 02:55, Lubos Lunak <l.lunak at suse.cz> wrote:
> >>
> >>  Hello,
> >>
> >>  could somebody please review the attached patch for PR14253?
> >>
> >>  The equivalent GCC patch has been accepted (GCC bug #55203) and
> libstdc++
> >> should use the attribute whenever I or somebody write the patch for it.
> >> Presumably this Clang patch should be followed by a patch for libc++ (I
> do
> >> not intend to do that).
> >>
> >> --
> >>  Lubos Lunak
> >>  l.lunak at suse.cz
> >>
> >> _______________________________________________
> >> cfe-commits mailing list
> >> cfe-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >>
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130716/5c8ea1a0/attachment.html>