[cfe-dev] Warning for static member accessed through dot or arrow

[Mat Sutcliffe via cfe-dev]

On 5 December 2016 at 09:05, Stephan Bergmann via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On 12/04/2016 11:20 PM, Mat Sutcliffe via cfe-dev wrote:
>
>> Comments?
>>
>
> In LibreOffice, we use a plugin to detect those (<
> https://cgit.freedesktop.org/libreoffice/core/tree/compile
> rplugins/clang/staticaccess.cxx>), for two reasons:
>
> * There were cases where removing the redundant object expression made
> some variables or function parameters become unused, which allowed further
> code clean-up.
>
> * In some cases MSVC indirectly warns about such redundant object
> expressions, when they involve otherwise unused function parameters
> (producing a warning about an unused parameter, which can be somewhat
> puzzling given the parameter /is/ used in the program text).  So we could
> just as well warn about these things consistently.
>
> On the other hand, these warnings are sometimes perceived as being on the
> border of "style police", so likely makes sense to have them only enabled
> explicitly.
>

Good to know. I went the route of implementing a compiler warning after I
read the following in <http://clang-analyzer.llvm.or
g/checker_dev_manual.html#ast>: "Some checks might not require
path-sensitivity to be effective. Simple AST walk might be sufficient. If
that is the case, consider implementing a Clang compiler warning."

So now the question is whether a plugin is satisfactory, or if there would
be sufficient benefit to having a warning available in the core compiler. I
believe there would be, but of course I am biased. The existence of a
plugin shows that there is at least one other user who desires this
feature, and that the concept has received a certain amount of testing
already. I think it meets the seven criteria at <
http://clang.llvm.org/get_involved.html>. The advantages of a warning
available in the vanilla compiler would be increased user reach, less
burdensome usage, exposure to more vigorous testing. I think the runtime
overhead would be negligible, as the diagnosis fits naturally into the
procedure for building a member access expression.

Maybe it's too simple an issue for anyone to waste time talking about, so
it might just be a case of submitting the patch and seeing what happens.
I'm just being extra cautious because it's my first patch to LLVM.
Coincidentally, this came up on StackOverflow just the other day: <
http://stackoverflow.com/q/41018973/1639256>

I don't have much to say on the overreach of the style police. Because of
the large body of user code that would trigger this warning, and which is
required by coding standards to compile cleanly with -Wall -Wextra it would
be disabled by default and not controlled by either of those flags. It
seems no more authoritarian than many existing warnings and I'm aware of no
potential false positives or justifiable leniency, except for cases I've
previously identified which can be easily filtered out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161212/89d9f2cf/attachment.html>