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

[Jonathan Roelofs via cfe-dev]

On 12/4/16 3:20 PM, Mat Sutcliffe via cfe-dev wrote:
> I would like to propose a new warning for clang, and submit a patch
> implementing it. This would be my first patch submitted to LLVM. The
> warning would catch constructs like this:
>
>     QThread t;
>     t.sleep(1);
>
> The casual reader (or even the writer) may assume this code causes the
> thread t to sleep, which is not the case. QThread::sleep is a static
> method, which causes the _current_ thread to sleep. The code could be
> rewritten to clarify the meaning/intent:
>
>     QThread::sleep(1);
>     // or:
>     decltype(t)::sleep(1);
>
> I do not propose enabling the warning by default, or including it in
> -Wall or -Wextra because of the large body of code in the wild that
> treats this construct as an idiomatic way to refer to static members. I
> propose the flag -Wunused-object-expression ("object expression" being
> the term used by the standard to denote the expression to the left of a
> member access operator).
>
> I was quite surprised that none of the compilers or static analyzers I
> tried would diagnose this, even at their highest warning levels, which
> leads me to question whether I am missing something. Could there be a
> legitimate reason not to transform a member access of a static member
> into an id-expression as in the above example? I can think of two cases
> in which the warning should be inhibited: implicit this-> and when the
> staticness of the member could depend on a template parameter. If the
> object expression has some side effects that the user wants to preserve,
> they can always be moved to a separate statement.
>
> Comments?

Sounds like a great candidate for a clang-tidy check (and possibly a 
fixup, too). Then you won't be held to quite as high standards w.r.t. 
false positives / false negatives as you would be with a clang warning. 
In addition, clang-tidy is a good "proving ground" for gathering data on 
FN's and FP's from large projects.


Cheers,

Jon

>
> Thanks
> Mat
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded