[cfe-dev] clang-tidy check: Uninitialised primitive members in constructors

[Jonathan Coe]

Thanks, this is very helpful.

clang-query>match
recordDecl(hasDescendant(fieldDecl(hasType(anyOf(builtinType(),
pointerType()))))

will find a class with pointer or builtin types. I'm not sure how to record
this to make use of it later.

I want to find any constructor (ignoring implicit ones for now) which
triggered this first match but left one of its builtin or pointer fields
uninitialised. I can't yet see how to iterate over fields as the
information I care about is which ones are not initialised and they'll be
missing from whatever constructor expression I'm matching.

I can live with false positives in the constructor body for now.

regards,

Jon





On 2 February 2015 at 19:25, Richard <legalize at xmission.com> wrote:

>
> In article <
> CAAbBDD_qERV4xufHtjBjgQT9m-1AsxretLTS_ABvQGGkeAOX+A at mail.gmail.com>,
>     Jonathan Coe <jbcoe at me.com> writes:
>
> > I'm looking to make use of a clang-tidy check that would find (and
> > optionally value-initialise) primitive class members (pointers, int,
> > doubles etc).
> >
> > class C
> > {
> >   int x_;
> > public:
> >   C() {} // no x_()
> > };
> >
> > Is this:
> >
> > 1) Already possible? (I can't find it)
>
> I believe so.
>
> > 2) Already work in progress? (I'd like to participate)
>
> I am interested in clang-tidy checkers/fixers that identify the same
> issues as cppcheck and this is something that they identify currently.
> You can use cppcheck as a reference checking mechanism.
>
> > 3) Possible at all?
>
> Yes.
>
> > 3. Is motivated by my very weak understanding of the matchers, I'm not
> sure
> > if I can match things that are missing if the missing things depend on
> the
> > node I'm looking at. It would be nice to match the compiler generated
> > constructor too (and generate one) if that would fail to initialise
> > primitives as required.
>
> I would play with clang-query and experiment with the matchers that
> you need to identify:
>
> - a class with POD members
> - a constructor for a class containing POD members
>
> Maybe you just match all class declarations and all constructors and
> you walk through the other information in code in order to identify
> "class with POD members".
>
> Your check can maintain state, so you can note that you don't have to
> do everything with your matcher.  You can record that you saw a class
> with POD members and that a c'tor was declared but not defined so
> that when you see the definition after the declaration you know this
> is a definition you should drill into more carefully.
>
> Remember that POD members can also be initialized by assignment in the
> c'tor, so you'll want to have that to avoid false positives.
>
> Start with the simplest case that you can identify accurately and
> correct.  A tool that works correctly for a subset of cases is still
> useful.  You can incrementally enhance the check over time to extend
> it to more elaborate cases.
>
> Work out of trunk.  A bunch of changes have been made to clang-tidy in
> trunk compared to 3.5.
>
> The best thing is probably to post questions to the list as you
> encounter them.
> --
> "The Direct3D Graphics Pipeline" free book <
> http://tinyurl.com/d3d-pipeline>
>      The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
>          The Terminals Wiki <http://terminals.classiccmp.org>
>   Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150202/a6081ab0/attachment.html>