[cfe-dev] Open Clang Project : Document Generation tool with Clang
vivek pandya via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 14 11:22:52 PST 2016
*Vivek Pandya*
On Thu, Jan 14, 2016 at 11:54 PM, via cfe-dev <cfe-dev at lists.llvm.org>
wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at 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 at lists.llvm.org
>
> You can reach the person managing the list at
> cfe-dev-owner at 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 at lists.llvm.org>
> To: Clang Dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report
> Message-ID: <56976E7A.80304 at 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
>
> On 12/22/2015 11:51 AM, Manuel Klimek wrote:
> > Adding the check id sounds like a useful feature.
> >
> > On Mon, Dec 21, 2015, 1:44 PM Ilia Gromov via cfe-dev
> > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> > 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 at lists.llvm.org <mailto:cfe-dev at 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 at lists.llvm.org>
> To: Ilia Gromov <ilia.gromov at oracle.com>
> Cc: Clang Dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report
> Message-ID:
> <CAOweq9+HWz7yHUfYeaZ9Gs4L8QiDd7=
> Adpe6LBE5AvtMVaxcqg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Could you send the patch via LLVM Phabricator
> <http://llvm.org/docs/Phabricator.html>, please? It's the preferred way to
> send clang-tidy patches.
>
> On Thu, Jan 14, 2016 at 10:46 AM, Ilia Gromov <ilia.gromov at oracle.com>
> wrote:
>
> > 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
> >
> > On 12/22/2015 11:51 AM, Manuel Klimek wrote:
> >
> > Adding the check id sounds like a useful feature.
> >
> > On Mon, Dec 21, 2015, 1:44 PM Ilia Gromov via cfe-dev <
> > cfe-dev at lists.llvm.org> wrote:
> >
> >> 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 at 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 at lists.llvm.org>
> To: Yury Gribov <y.gribov at samsung.com>
> Cc: "<Alexander G. Riccio>" <test35965 at gmail.com>, cfe-dev
> <cfe-dev at 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 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jan 13, 2016 at 12:57 AM, Yury Gribov via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > On 01/13/2016 04:20 AM, <Alexander G. Riccio> via cfe-dev wrote:
> >>>
> >>> 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>
> >>
> >> If left to my own devices, I will build more.
> >> ⁂
> >>
> >> On Tue, Jan 12, 2016 at 7:06 PM, Devin Coughlin <dcoughlin at apple.com>
> >> wrote:
> >>
> >>> 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
> >>>
> >>> On Jan 12, 2016, at 2:22 PM, Alexander Riccio via cfe-dev <
> >>> cfe-dev at lists.llvm.org> wrote:
> >>>
> >>> 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 at google.com>
> >>> Sent: 1/12/2016 5:18 PM
> >>> To: <Alexander G. Riccio> <test35965 at gmail.com>; Jordan Rose
> >>> <jordan_rose at apple.com>
> >>> Cc: cfe-dev <cfe-dev at 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.
> >>>
> >>> On Sun, Jan 3, 2016 at 10:31 PM, <Alexander G. Riccio> via cfe-dev <
> >>> cfe-dev at lists.llvm.org> wrote:
> >>>
> >>>> Is it because the checker is *unix*.malloc
> >>>> <http://clang-analyzer.llvm.org/available_checks.html#unix_checkers>?
> 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>
> >>>> If left to my own devices, I will build more.
> >>>> ⁂
> >>>>
> >>>> On Sat, Jan 2, 2016 at 3:57 PM, <Alexander G. Riccio> <
> >>>> test35965 at gmail.com> wrote:
> >>>>
> >>>>> 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>
> >>>>> If left to my own devices, I will build more.
> >>>>> ⁂
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> cfe-dev mailing list
> >>>> cfe-dev at lists.llvm.org
> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>>
> >>>>
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> cfe-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at 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 at lists.llvm.org>
> To: cfe-dev at lists.llvm.org
> Subject: Re: [cfe-dev] Open Clang Project : Document Generation tool
> with Clang
> Message-ID: <loom.20160114T185649-198 at post.gmane.org>
> Content-Type: text/plain; charset=utf-8
>
> vivek pandya via cfe-dev <cfe-dev at ...> 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
>
> Barbara
> DoxyPress Co-founder
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ------------------------------
>
> End of cfe-dev Digest, Vol 103, Issue 41
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160115/4efd313d/attachment.html>
More information about the cfe-dev
mailing list