Open Clang Project : Document Generation tool with Clang

*Vivek Pandya*

Send cfe-dev mailing list submissions to
        cfe-dev@lists.llvm.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        cfe-dev-request@lists.llvm.org

You can reach the person managing the list at
        cfe-dev-owner@lists.llvm.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."

Today's Topics:

   1. Re: [clang-tidy] Addition info in YAML report
      (Ilia Gromov via cfe-dev)
   2. Re: [clang-tidy] Addition info in YAML report
      (Alexander Kornienko via cfe-dev)
   3. Re: Clang on Windows fails to detect trivial double free
      instatic analysis (Aaron Ballman via cfe-dev)
   4. Re: Open Clang Project : Document Generation tool with Clang
      (Barbara Geller via cfe-dev)

----------------------------------------------------------------------

Message: 1
Date: Thu, 14 Jan 2016 13:46:34 +0400
From: Ilia Gromov via cfe-dev <cfe-dev@lists.llvm.org>
To: Clang Dev <cfe-dev@lists.llvm.org>
Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report
Message-ID: <56976E7A.80304@oracle.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

I made a *patch* which adds check ID and filed a bug [
https://llvm.org/bugs/show_bug.cgi?id=26132 ] (See the patch there).
I hope it can be reviewed and applied soon, because it will be really
useful to be able to group and filter results after clang-tidy did his
work.

Thanks,
Ilia Gromov

> Adding the check id sounds like a useful feature.
>
>
> Hi,
>
> clang-tidy saves a YAML report when the option '-export-fixes=...>
> is used.
>
> ---
> MainSourceFile: ''
> Replacements:
> - FilePath: /home/ilia/clang/sandbox/main.cpp
> Offset: 388
> Length: 8
> ReplacementText: '// TODO(ilia): '
> ...
>
> This information is sufficient to apply generated replacements later.
> However, there is no information about a check which had found
> this warning.
>
> Is there a way to know check ID for this replacement?
>
>
> PS:
> In clang-modernize this problem was solved with a workaround:
> When in "serialize-replacements" mode, clang-modernize can't inspect
> sources more than for 1 check ID.
> So, when I run
>
> ./clang-modernize -serialize-replacements
> -serialize-dir=/tmp/modernize/add-override112233 /tmp/source.cpp
>
> I'm sure that a YAML file in /tmp/modernize/add-override112233 is for
> "add-override" check.Repeat this for all 6 checks and, as a
> result, you
> can group replacements by check ID.
> clang-tidy allows to specify any number of check IDs when saving to
> YAML. And it has way more checks than 6. So, this workaround won't
> work
> well in case of clang-tidy
>
> --
>
> Thanks,
> Ilia Gromov
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org <mailto:cfe-dev@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/21548175/attachment-0001.html
>

------------------------------

Message: 2
Date: Thu, 14 Jan 2016 11:50:15 +0100
From: Alexander Kornienko via cfe-dev <cfe-dev@lists.llvm.org>
To: Ilia Gromov <ilia.gromov@oracle.com>
Cc: Clang Dev <cfe-dev@lists.llvm.org>
Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report
Message-ID:
        <CAOweq9+HWz7yHUfYeaZ9Gs4L8QiDd7=
Adpe6LBE5AvtMVaxcqg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Could you send the patch via LLVM Phabricator
<http://llvm.org/docs/Phabricator.html&gt;, please? It's the preferred way to
send clang-tidy patches.

> I made a *patch* which adds check ID and filed a bug [
> https://llvm.org/bugs/show_bug.cgi?id=26132 ] (See the patch there).
> I hope it can be reviewed and applied soon, because it will be really
> useful to be able to group and filter results after clang-tidy did his
work.
>
> Thanks,
> Ilia Gromov
>
>
> Adding the check id sounds like a useful feature.
>
>
>> Hi,
>>
>> clang-tidy saves a YAML report when the option '-export-fixes=...> is
>> used.
>>
>> ---
>> MainSourceFile: ''
>> Replacements:
>> - FilePath: /home/ilia/clang/sandbox/main.cpp
>> Offset: 388
>> Length: 8
>> ReplacementText: '// TODO(ilia): '
>> ...
>>
>> This information is sufficient to apply generated replacements later.
>> However, there is no information about a check which had found this
>> warning.
>>
>> Is there a way to know check ID for this replacement?
>>
>>
>> PS:
>> In clang-modernize this problem was solved with a workaround:
>> When in "serialize-replacements" mode, clang-modernize can't inspect
>> sources more than for 1 check ID.
>> So, when I run
>>
>> ./clang-modernize -serialize-replacements
>> -serialize-dir=/tmp/modernize/add-override112233 /tmp/source.cpp
>>
>> I'm sure that a YAML file in /tmp/modernize/add-override112233 is for
>> "add-override" check.Repeat this for all 6 checks and, as a result, you
>> can group replacements by check ID.
>> clang-tidy allows to specify any number of check IDs when saving to
>> YAML. And it has way more checks than 6. So, this workaround won't work
>> well in case of clang-tidy
>>
>> --
>>
>> Thanks,
>> Ilia Gromov
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/bd892121/attachment-0001.html
>

------------------------------

Message: 3
Date: Thu, 14 Jan 2016 08:26:36 -0500
From: Aaron Ballman via cfe-dev <cfe-dev@lists.llvm.org>
To: Yury Gribov <y.gribov@samsung.com>
Cc: "<Alexander G. Riccio>" <test35965@gmail.com>, cfe-dev
        <cfe-dev@lists.llvm.org>
Subject: Re: [cfe-dev] Clang on Windows fails to detect trivial double
        free instatic analysis
Message-ID:
        <CAAt6xTu9dbv2-wOoae96=J_zFeR_uyOWLFQgx5Frp5=
051t_nQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

>>>
>>> My understanding is that this is in the “unix” package for historical
>>
>> reasons from before the analyzer thought about Windows. We have clients
>> that rely on the malloc checker being enabled/disabled with
‘unix.Malloc'
>> so moving it will break compatibility.
>>
>> Gahh, ok. Not breaking things is a good reason.
>
>
> Why not implement checker synonyms? This sounds like a general problem.

This is what clang-tidy did for its checkers, and it seems like the
static analyzer could maybe benefit from the same feature. I can
foresee use for such a thing if, for instance, people wanted to add
static analysis checks for various coding guidelines that have
overlapping requirements.

~Aaron

>
>>> I discussed this off-list with Anna Zaks. She recommended changing the
>>
>> driver to enable unix.Malloc explicitly when running in a Windows MSVC
>> environment. This is Clang::ConstructJob() in Tools.cpp. We currently
skip
>> enabling the “unix” package there for Windows MSVC.
>>
>> Yup, that'd be a good short term fix.
>>
>>> Someone who develops on Windows should write a patch and test it.
>>
>> Alexander: would you be willing to do this? It should be very
>> straightforward — there is similar code to disable specific checkers for
>> PS4.
>>
>> Yup! I could very well do that. I think the change would look something
>> like:
>>
>> if (!IsWindowsMSVC)
>> CmdArgs.push_back("-analyzer-checker=unix.Malloc");
>>
>>> We should also add a comment Checkers.td to indicate that we should
move
>>
>> the Malloc checker to another package when we do remap packages names
and
>> break backward compatibility. “core” is probably not the right place for
>> this (since malloc() is in the standard library). Maybe a new “cstdlib”
>> package?
>>
>> (that's what I meant by "short term fix")
>> "cstdlib" makes more sense - core was just the first thing that came to
>> mind - and we could make cstdlib.malloc/cstdlib.Malloc alias unix.Malloc
>> to
>> avoid breaking users of unix.Malloc.
>>
>> Sidenote: has anybody ever considered diagnosing incorrectly capitalized
>> checker name arguments? It's not terribly important, but I was quite
>> annoyed to find out that I'd spent a couple hours debugging a lowercase
>> "M".
>>
>> Sincerely,
>> Alexander Riccio
>> --
>> "Change the world or go home."
>> about.me/ariccio
>>
>> <http://about.me/ariccio&gt;
>>
>> If left to my own devices, I will build more.
>> ⁂
>>
>>
>>> My understanding is that this is in the “unix” package for historical
>>> reasons from before the analyzer thought about Windows. We have clients
>>> that rely on the malloc checker being enabled/disabled with
‘unix.Malloc'
>>> so moving it will break compatibility.
>>>
>>> I discussed this off-list with Anna Zaks. She recommended changing the
>>> driver to enable unix.Malloc explicitly when running in a Windows MSVC
>>> environment. This is Clang::ConstructJob() in Tools.cpp. We currently
>>> skip
>>> enabling the “unix” package there for Windows MSVC.
>>>
>>> Someone who develops on Windows should write a patch and test it.
>>> Alexander: would you be willing to do this? It should be very
>>> straightforward — there is similar code to disable specific checkers
for
>>> PS4.
>>>
>>> We should also add a comment Checkers.td to indicate that we should
move
>>> the Malloc checker to another package when we do remap packages names
and
>>> break backward compatibility. “core” is probably not the right place
for
>>> this (since malloc() is in the standard library). Maybe a new “cstdlib”
>>> package?
>>>
>>> Devin
>>>
>>>
>>> Shoot - I haven't responded to this. I did some debugging the other day
>>> and found that if I manually pass the flag to enable the unix.Malloc
>>> checker (that's a capital "M", as I discovered the hard way), Clang
>>> detects
>>> this.
>>>
>>> I was going to suggest something like enabling it by default (obvious),
>>> and *maybe* renaming it to something like core.Malloc, because it's not
>>> unix-specific.
>>>
>>> The one benefit here of parsing SAL is a more generic mechanism, but
>>> that's a different issue.
>>>
>>> sent from my (stupid) windows phone
>>> ------------------------------
>>> From: Reid Kleckner <rnk@google.com>
>>> Sent: ‎1/‎12/‎2016 5:18 PM
>>> To: <Alexander G. Riccio> <test35965@gmail.com>; Jordan Rose
>>> <jordan_rose@apple.com>
>>> Cc: cfe-dev <cfe-dev@lists.llvm.org>
>>> Subject: Re: [cfe-dev] Clang on Windows fails to detect trivial double
>>> free instatic analysis
>>>
>>> Jordan, how do we enable this checker on Windows?
>>>
>>> We shouldn't need to be able to parse SAL to do this analysis.
>>>
>>>
>>>> Is it because the checker is *unix*.malloc
>>>> <http://clang-analyzer.llvm.org/available_checks.html#unix_checkers&gt;?
If
>>>> so, that's actually quite terrible... why only check it on unix??
>>>>
>>>> Sincerely,
>>>> Alexander Riccio
>>>> --
>>>> "Change the world or go home."
>>>> about.me/ariccio
>>>>
>>>> <http://about.me/ariccio&gt;
>>>> If left to my own devices, I will build more.
>>>> ⁂
>>>>
>>>>
>>>>> When I build the attached C program in windows, using Clang built
from
>>>>> a
>>>>> very recent tree version (trunk 256686), Clang fails to detect the
>>>>> trivial
>>>>> double free, as evidenced in the resulting plist file (attached).
>>>>>
>>>>> What's going on here? I have a gut feeling that it has something to
do
>>>>> with Clang's ignorance of SAL, which allows MSVC to detect the
>>>>> condition
>>>>> generically:
>>>>>
>>>>> void __cdecl free(
>>>>> _Pre_maybenull_ _Post_invalid_ void* _Block
>>>>> );
>>>>>
>>>>> (from C:/Program Files (x86)/Windows
>>>>> Kits/10/Include/10.0.10240.0/ucrt/corecrt_malloc.h)
>>>>>
>>>>> I'm also attaching the verbose compilation output.
>>>>>
>>>>> Sincerely,
>>>>> Alexander Riccio
>>>>> --
>>>>> "Change the world or go home."
>>>>> about.me/ariccio
>>>>>
>>>>> <http://about.me/ariccio&gt;
>>>>> If left to my own devices, I will build more.
>>>>> ⁂
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

------------------------------

Message: 4
Date: Thu, 14 Jan 2016 18:08:43 +0000 (UTC)
From: Barbara Geller via cfe-dev <cfe-dev@lists.llvm.org>
To: cfe-dev@lists.llvm.org
Subject: Re: [cfe-dev] Open Clang Project : Document Generation tool
        with Clang
Message-ID: <loom.20160114T185649-198@post.gmane.org>
Content-Type: text/plain; charset=utf-8

vivek pandya via cfe-dev <cfe-dev@...> writes:

> Hello,
> I have read about this open project on clang open project page.
> What would be the advantage of using clang libs to implement doxygen like
> tool ? I mean is there any use-case that are not implemented in doxygen
but
> with clang it can be implemented. Could some one explain this in a bit
detail ?
> I am currently experimenting with libClang to generate documents from
> Objective-C (via comments like doxygen ) but my hunch is that generating
> docs for C++ would be more difficult.
> Sincerely,
>
>
> Vivek Pandya
> P.S : I would like to apply for this project in GSoC 2016. How important
> is it for clang community.

We are currently in the process of integrating libclang with DoxyPress for
C++ parsing in lieu of the current lex based parser. We are very interested
in having other developers participate in this process.

If you or anyone else would like to work with us directly or through GSoC
2016 we would be very interested.

For me working during vacation (GSoC) is preferred. To get accepted in GSoC
, I have to make a clear proposal for the work and also a time line. For
making a solid proposal I require DoxyPress source code so that I can
analyze what is need to be done particularly to use libclang into it and
what other benefits can be achieved with it.
I have seen your Cpp con video and I think you are planning to share the
code on github.com
- Vivek