[cfe-dev] clang-tidy/clang-query issues

[Manuel Klimek via cfe-dev]

Use clang-check to do the ast dump otherwise you have to specify the full
command line. The 'invalid' in your dump indicates that there were parse
errors, most likely due to headers that clang didn't find.

On Tue, Jul 12, 2016, 1:12 AM Andre-Marcel Hellmund <hellmund at fzi.de> wrote:

> Hi Aaron, Hi Manuel,
>
> thank you for your prompt reply and sorry for my belated response!
> Regarding the header omp.h, I meanwhile figured out that my clang-3.8
> installation (from the official apt-repo) does not include the omp.h header
> file. If I add the omp.h from gcc, the error is gone, while others appear.
> But this is not your problem. :-D
>
> Regarding the second issue with incorrect AST matches, this is the reduced
> C++ code structure out of a larger C++ header file:
>
> [...] many class definitions [...]
>
> class RoadLink {
> public:
>     [...]
> private:
>     std::vector<int64_t> precedingRoads_;
>     std::vector<int64_t> succeedingRoads_;
> };
>
> class Road {
> public:
>     [...]
>     std::vector<LaneSectionPtr>::const_iterator sectionsBegin() const {
>         return sections_.cbegin();
>     }
>
>
> private:
>     int64_t roadID_;
>     std::vector<LaneSectionPtr> sections_;
>     RoadLink roadLink_;
>     const odd::RoadDescriptor* roadDesc_;
> }
>
> class MetaData {
> public:
>     [...]
> private:
>     double xMin_;
>     double xMax_;
>     double yMin_;
>     double yMax_;
> };
>
> When I run the clang-query matcher, I get sections_ and roadLink_ as
> public field decls for class Road. The private members of the class before
> and after the class 'Road' are correctly matched. If I look at the ast-dump
> for the class Road, I see the following shortened dump:
>
> | |-CXXRecordDecl 0x9c7b668 prev 0x9c6bac0 <line:492:1, line:531:1>
> line:492:7 referenced invalid class Road definition
> | | |-AccessSpecDecl 0x9c7b7e8 <line:493:1, col:7> col:1 public
> | | |-FieldDecl 0x9c7bff0 <line:510:32, col:34> col:34 invalid
> const_iterator 'int'
> | | |-FieldDecl 0x9c7c048 <line:528:33> col:33 invalid sections_ 'int'
> | | |-FieldDecl 0x9c7c0a0 <line:529:5, col:14> col:14 invalid roadLink_
> 'class opendrive::RoadLink'
> | | `-FieldDecl 0x9c7c140 <line:530:5, col:32> col:32 roadDesc_ 'const
> odd::RoadDescriptor *'
>
> So, I see a few errors in this AST:
>
> 1. The AccessSpecDecl 'private' is missing in this class, while it is
> available preceding and succeeding class
> 2. The const_iterator from line 510 (Function: sectionsBegin()) is added
> as a field decl while it is a type of the std::vector.
>
> BTW, the AST dump was generated by clang-3.9 (ToT, last week).
>
> Do you have any idea what could be wrong here?
>
> Thanks,
> Andi
>
>
>
>
>
> On 07.07.2016 14:39, Manuel Klimek wrote:
>
> On Thu, Jul 7, 2016 at 8:31 AM Andre-Marcel Hellmund via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi Clang-Guys,
>>
>> I recently started to look into the clang-tools to enforce coding
>> guidelines for our development group. Therefore, I played around with
>> clang-tidy and clang-format (version 3.8 and trunk from Monday), however
>> ran into a two problems. Before I dive deeper into the code details of
>> both tools, I would like to check with you for known issues or hints.
>>
>> 1) While the compilation of the code using CMake (ninja) works fine,
>> loading the same code via clang-tidy (and the compilation database)
>> results in an error that a header, omp.h, could not be found. Is this a
>> known bug for clang-tidy or might this be caused by a defect in CMake?
>>
>
> This is really hard to diagnose without more info.
>
>
>> 2) Performing a simple AST match (reduced from the clang-tidy check
>> 'readability-identifier-naming'), that is,
>>
>> fieldDecl(isPublic()).bind("public_member")
>>
>> results in incorrect matches meaning that privately declared members or
>> public type definitions of std containers like const_iterator are
>> matched. Interestingly, I was not yet able to reproduce those errors
>> with simplified test cases. Are there some known issues with the AST
>> matchers that could fit my description?
>>
>
> The only known issue is that it's often hard to intuitively understand why
> things are in the AST. It would be great to have a smaller repro of your
> problem, otherwise it's really hard to help.
>
>
>>
>> Thank you for your help and support in advance,
>> Andi
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> --
> .........................................................
> André-Marcel Hellmund, M.Sc.
> Wissenschaftlicher Mitarbeiter | Scientific Researcher
> Mobile Perception Systems
>
> FZI Forschungszentrum Informatik
> Haid-und-Neu-Str. 10–14
> 76131 Karlsruhe, Germany
>
> Tel.: +49 721 608-47146
> Fax: +49 721 661874
> hellmund at fzi.dewww.fzi.de/mitarbeiter/hellmund
> .........................................................
> FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
> Stiftung des bürgerlichen Rechts
> Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
> Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
> Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> .........................................................
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160712/1291d248/attachment.html>