On Tuesday 16 of July 2013, David Blaikie 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).
That may work in an ideal world, but I think in practice the exceptions will be what matters. As long as there's a single type missing the annotation (which is quite likely, with projects using a number of libraries from different providers, etc.), there are likely to be false positives. And I bet a number of developers would be rather unhappy to find out that a new compiler means they have to somehow work around false warnings about this and that 3rd-party library or just disable the warning altogether. Moreover, in practice it's quite likely that tagging the most obvious 5% will trigger 95% or more of possible (warranted) warnings, as there are only certain kinds of classes that are likely to have unused variables. There may be a bunch of unused StringRef variables in Clang, but I rather doubt you'll find a single unused variable of say FunctionDecl. So while the patch is not perfect, I think it's good enough. That said, if you do have a better idea, I'm interested. > 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 There is no "the way GCC does". I wrote both of the patches. -- Lubos Lunak [email protected] _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
