<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><i><font size="2" face="monospace, monospace"><b>Vivek Pandya</b></font></i><div><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Jan 14, 2016 at 11:54 PM, via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cfe-dev mailing list submissions to<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cfe-dev-request@lists.llvm.org">cfe-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cfe-dev-owner@lists.llvm.org">cfe-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [clang-tidy] Addition info in YAML report<br>
(Ilia Gromov via cfe-dev)<br>
2. Re: [clang-tidy] Addition info in YAML report<br>
(Alexander Kornienko via cfe-dev)<br>
3. Re: Clang on Windows fails to detect trivial double free<br>
instatic analysis (Aaron Ballman via cfe-dev)<br>
4. Re: Open Clang Project : Document Generation tool with Clang<br>
(Barbara Geller via cfe-dev)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 14 Jan 2016 13:46:34 +0400<br>
From: Ilia Gromov via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report<br>
Message-ID: <<a href="mailto:56976E7A.80304@oracle.com">56976E7A.80304@oracle.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
I made a *patch* which adds check ID and filed a bug [<br>
<a href="https://llvm.org/bugs/show_bug.cgi?id=26132" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26132</a> ] (See the patch there).<br>
I hope it can be reviewed and applied soon, because it will be really<br>
useful to be able to group and filter results after clang-tidy did his work.<br>
<br>
Thanks,<br>
Ilia Gromov<br>
<br>
On 12/22/2015 11:51 AM, Manuel Klimek wrote:<br>
> Adding the check id sounds like a useful feature.<br>
><br>
> On Mon, Dec 21, 2015, 1:44 PM Ilia Gromov via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> clang-tidy saves a YAML report when the option '-export-fixes=...><br>
> is used.<br>
><br>
> ---<br>
> MainSourceFile: ''<br>
> Replacements:<br>
> - FilePath: /home/ilia/clang/sandbox/main.cpp<br>
> Offset: 388<br>
> Length: 8<br>
> ReplacementText: '// TODO(ilia): '<br>
> ...<br>
><br>
> This information is sufficient to apply generated replacements later.<br>
> However, there is no information about a check which had found<br>
> this warning.<br>
><br>
> Is there a way to know check ID for this replacement?<br>
><br>
><br>
> PS:<br>
> In clang-modernize this problem was solved with a workaround:<br>
> When in "serialize-replacements" mode, clang-modernize can't inspect<br>
> sources more than for 1 check ID.<br>
> So, when I run<br>
><br>
> ./clang-modernize -serialize-replacements<br>
> -serialize-dir=/tmp/modernize/add-override112233 /tmp/source.cpp<br>
><br>
> I'm sure that a YAML file in /tmp/modernize/add-override112233 is for<br>
> "add-override" check.Repeat this for all 6 checks and, as a<br>
> result, you<br>
> can group replacements by check ID.<br>
> clang-tidy allows to specify any number of check IDs when saving to<br>
> YAML. And it has way more checks than 6. So, this workaround won't<br>
> work<br>
> well in case of clang-tidy<br>
><br>
> --<br>
><br>
> Thanks,<br>
> Ilia Gromov<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/21548175/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/21548175/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 14 Jan 2016 11:50:15 +0100<br>
From: Alexander Kornienko via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Ilia Gromov <<a href="mailto:ilia.gromov@oracle.com">ilia.gromov@oracle.com</a>><br>
Cc: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] [clang-tidy] Addition info in YAML report<br>
Message-ID:<br>
<CAOweq9+HWz7yHUfYeaZ9Gs4L8QiDd7=<a href="mailto:Adpe6LBE5AvtMVaxcqg@mail.gmail.com">Adpe6LBE5AvtMVaxcqg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Could you send the patch via LLVM Phabricator<br>
<<a href="http://llvm.org/docs/Phabricator.html" rel="noreferrer" target="_blank">http://llvm.org/docs/Phabricator.html</a>>, please? It's the preferred way to<br>
send clang-tidy patches.<br>
<br>
On Thu, Jan 14, 2016 at 10:46 AM, Ilia Gromov <<a href="mailto:ilia.gromov@oracle.com">ilia.gromov@oracle.com</a>><br>
wrote:<br>
<br>
> I made a *patch* which adds check ID and filed a bug [<br>
> <a href="https://llvm.org/bugs/show_bug.cgi?id=26132" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26132</a> ] (See the patch there).<br>
> I hope it can be reviewed and applied soon, because it will be really<br>
> useful to be able to group and filter results after clang-tidy did his work.<br>
><br>
> Thanks,<br>
> Ilia Gromov<br>
><br>
> On 12/22/2015 11:51 AM, Manuel Klimek wrote:<br>
><br>
> Adding the check id sounds like a useful feature.<br>
><br>
> On Mon, Dec 21, 2015, 1:44 PM Ilia Gromov via cfe-dev <<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> clang-tidy saves a YAML report when the option '-export-fixes=...> is<br>
>> used.<br>
>><br>
>> ---<br>
>> MainSourceFile: ''<br>
>> Replacements:<br>
>> - FilePath: /home/ilia/clang/sandbox/main.cpp<br>
>> Offset: 388<br>
>> Length: 8<br>
>> ReplacementText: '// TODO(ilia): '<br>
>> ...<br>
>><br>
>> This information is sufficient to apply generated replacements later.<br>
>> However, there is no information about a check which had found this<br>
>> warning.<br>
>><br>
>> Is there a way to know check ID for this replacement?<br>
>><br>
>><br>
>> PS:<br>
>> In clang-modernize this problem was solved with a workaround:<br>
>> When in "serialize-replacements" mode, clang-modernize can't inspect<br>
>> sources more than for 1 check ID.<br>
>> So, when I run<br>
>><br>
>> ./clang-modernize -serialize-replacements<br>
>> -serialize-dir=/tmp/modernize/add-override112233 /tmp/source.cpp<br>
>><br>
>> I'm sure that a YAML file in /tmp/modernize/add-override112233 is for<br>
>> "add-override" check.Repeat this for all 6 checks and, as a result, you<br>
>> can group replacements by check ID.<br>
>> clang-tidy allows to specify any number of check IDs when saving to<br>
>> YAML. And it has way more checks than 6. So, this workaround won't work<br>
>> well in case of clang-tidy<br>
>><br>
>> --<br>
>><br>
>> Thanks,<br>
>> Ilia Gromov<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/bd892121/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/attachments/20160114/bd892121/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 14 Jan 2016 08:26:36 -0500<br>
From: Aaron Ballman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Yury Gribov <<a href="mailto:y.gribov@samsung.com">y.gribov@samsung.com</a>><br>
Cc: "<Alexander G. Riccio>" <<a href="mailto:test35965@gmail.com">test35965@gmail.com</a>>, cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] Clang on Windows fails to detect trivial double<br>
free instatic analysis<br>
Message-ID:<br>
<CAAt6xTu9dbv2-wOoae96=J_zFeR_uyOWLFQgx5Frp5=<a href="mailto:051t_nQ@mail.gmail.com">051t_nQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Wed, Jan 13, 2016 at 12:57 AM, Yury Gribov via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> On 01/13/2016 04:20 AM, <Alexander G. Riccio> via cfe-dev wrote:<br>
>>><br>
>>> My understanding is that this is in the “unix” package for historical<br>
>><br>
>> reasons from before the analyzer thought about Windows. We have clients<br>
>> that rely on the malloc checker being enabled/disabled with ‘unix.Malloc'<br>
>> so moving it will break compatibility.<br>
>><br>
>> Gahh, ok. Not breaking things is a good reason.<br>
><br>
><br>
> Why not implement checker synonyms? This sounds like a general problem.<br>
<br>
This is what clang-tidy did for its checkers, and it seems like the<br>
static analyzer could maybe benefit from the same feature. I can<br>
foresee use for such a thing if, for instance, people wanted to add<br>
static analysis checks for various coding guidelines that have<br>
overlapping requirements.<br>
<br>
~Aaron<br>
<br>
><br>
>>> I discussed this off-list with Anna Zaks. She recommended changing the<br>
>><br>
>> driver to enable unix.Malloc explicitly when running in a Windows MSVC<br>
>> environment. This is Clang::ConstructJob() in Tools.cpp. We currently skip<br>
>> enabling the “unix” package there for Windows MSVC.<br>
>><br>
>> Yup, that'd be a good short term fix.<br>
>><br>
>>> Someone who develops on Windows should write a patch and test it.<br>
>><br>
>> Alexander: would you be willing to do this? It should be very<br>
>> straightforward — there is similar code to disable specific checkers for<br>
>> PS4.<br>
>><br>
>> Yup! I could very well do that. I think the change would look something<br>
>> like:<br>
>><br>
>> if (!IsWindowsMSVC)<br>
>> CmdArgs.push_back("-analyzer-checker=unix.Malloc");<br>
>><br>
>>> We should also add a comment Checkers.td to indicate that we should move<br>
>><br>
>> the Malloc checker to another package when we do remap packages names and<br>
>> break backward compatibility. “core” is probably not the right place for<br>
>> this (since malloc() is in the standard library). Maybe a new “cstdlib”<br>
>> package?<br>
>><br>
>> (that's what I meant by "short term fix")<br>
>> "cstdlib" makes more sense - core was just the first thing that came to<br>
>> mind - and we could make cstdlib.malloc/cstdlib.Malloc alias unix.Malloc<br>
>> to<br>
>> avoid breaking users of unix.Malloc.<br>
>><br>
>> Sidenote: has anybody ever considered diagnosing incorrectly capitalized<br>
>> checker name arguments? It's not terribly important, but I was quite<br>
>> annoyed to find out that I'd spent a couple hours debugging a lowercase<br>
>> "M".<br>
>><br>
>> Sincerely,<br>
>> Alexander Riccio<br>
>> --<br>
>> "Change the world or go home."<br>
>> <a href="http://about.me/ariccio" rel="noreferrer" target="_blank">about.me/ariccio</a><br>
>><br>
>> <<a href="http://about.me/ariccio" rel="noreferrer" target="_blank">http://about.me/ariccio</a>><br>
>><br>
>> If left to my own devices, I will build more.<br>
>> ⁂<br>
>><br>
>> On Tue, Jan 12, 2016 at 7:06 PM, Devin Coughlin <<a href="mailto:dcoughlin@apple.com">dcoughlin@apple.com</a>><br>
>> wrote:<br>
>><br>
>>> My understanding is that this is in the “unix” package for historical<br>
>>> reasons from before the analyzer thought about Windows. We have clients<br>
>>> that rely on the malloc checker being enabled/disabled with ‘unix.Malloc'<br>
>>> so moving it will break compatibility.<br>
>>><br>
>>> I discussed this off-list with Anna Zaks. She recommended changing the<br>
>>> driver to enable unix.Malloc explicitly when running in a Windows MSVC<br>
>>> environment. This is Clang::ConstructJob() in Tools.cpp. We currently<br>
>>> skip<br>
>>> enabling the “unix” package there for Windows MSVC.<br>
>>><br>
>>> Someone who develops on Windows should write a patch and test it.<br>
>>> Alexander: would you be willing to do this? It should be very<br>
>>> straightforward — there is similar code to disable specific checkers for<br>
>>> PS4.<br>
>>><br>
>>> We should also add a comment Checkers.td to indicate that we should move<br>
>>> the Malloc checker to another package when we do remap packages names and<br>
>>> break backward compatibility. “core” is probably not the right place for<br>
>>> this (since malloc() is in the standard library). Maybe a new “cstdlib”<br>
>>> package?<br>
>>><br>
>>> Devin<br>
>>><br>
>>> On Jan 12, 2016, at 2:22 PM, Alexander Riccio via cfe-dev <<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> Shoot - I haven't responded to this. I did some debugging the other day<br>
>>> and found that if I manually pass the flag to enable the unix.Malloc<br>
>>> checker (that's a capital "M", as I discovered the hard way), Clang<br>
>>> detects<br>
>>> this.<br>
>>><br>
>>> I was going to suggest something like enabling it by default (obvious),<br>
>>> and *maybe* renaming it to something like core.Malloc, because it's not<br>
>>> unix-specific.<br>
>>><br>
>>> The one benefit here of parsing SAL is a more generic mechanism, but<br>
>>> that's a different issue.<br>
>>><br>
>>> sent from my (stupid) windows phone<br>
>>> ------------------------------<br>
>>> From: Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
>>> Sent: 1/12/2016 5:18 PM<br>
>>> To: <Alexander G. Riccio> <<a href="mailto:test35965@gmail.com">test35965@gmail.com</a>>; Jordan Rose<br>
>>> <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>><br>
>>> Cc: cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
>>> Subject: Re: [cfe-dev] Clang on Windows fails to detect trivial double<br>
>>> free instatic analysis<br>
>>><br>
>>> Jordan, how do we enable this checker on Windows?<br>
>>><br>
>>> We shouldn't need to be able to parse SAL to do this analysis.<br>
>>><br>
>>> On Sun, Jan 3, 2016 at 10:31 PM, <Alexander G. Riccio> via cfe-dev <<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>>> Is it because the checker is *unix*.malloc<br>
>>>> <<a href="http://clang-analyzer.llvm.org/available_checks.html#unix_checkers" rel="noreferrer" target="_blank">http://clang-analyzer.llvm.org/available_checks.html#unix_checkers</a>>? If<br>
>>>> so, that's actually quite terrible... why only check it on unix??<br>
>>>><br>
>>>> Sincerely,<br>
>>>> Alexander Riccio<br>
>>>> --<br>
>>>> "Change the world or go home."<br>
>>>> <a href="http://about.me/ariccio" rel="noreferrer" target="_blank">about.me/ariccio</a><br>
>>>><br>
>>>> <<a href="http://about.me/ariccio" rel="noreferrer" target="_blank">http://about.me/ariccio</a>><br>
>>>> If left to my own devices, I will build more.<br>
>>>> ⁂<br>
>>>><br>
>>>> On Sat, Jan 2, 2016 at 3:57 PM, <Alexander G. Riccio> <<br>
>>>> <a href="mailto:test35965@gmail.com">test35965@gmail.com</a>> wrote:<br>
>>>><br>
>>>>> When I build the attached C program in windows, using Clang built from<br>
>>>>> a<br>
>>>>> very recent tree version (trunk 256686), Clang fails to detect the<br>
>>>>> trivial<br>
>>>>> double free, as evidenced in the resulting plist file (attached).<br>
>>>>><br>
>>>>> What's going on here? I have a gut feeling that it has something to do<br>
>>>>> with Clang's ignorance of SAL, which allows MSVC to detect the<br>
>>>>> condition<br>
>>>>> generically:<br>
>>>>><br>
>>>>> void __cdecl free(<br>
>>>>> _Pre_maybenull_ _Post_invalid_ void* _Block<br>
>>>>> );<br>
>>>>><br>
>>>>> (from C:/Program Files (x86)/Windows<br>
>>>>> Kits/10/Include/10.0.10240.0/ucrt/corecrt_malloc.h)<br>
>>>>><br>
>>>>> I'm also attaching the verbose compilation output.<br>
>>>>><br>
>>>>> Sincerely,<br>
>>>>> Alexander Riccio<br>
>>>>> --<br>
>>>>> "Change the world or go home."<br>
>>>>> <a href="http://about.me/ariccio" rel="noreferrer" target="_blank">about.me/ariccio</a><br>
>>>>><br>
>>>>> <<a href="http://about.me/ariccio" rel="noreferrer" target="_blank">http://about.me/ariccio</a>><br>
>>>>> If left to my own devices, I will build more.<br>
>>>>> ⁂<br>
>>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>>>><br>
>>>><br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 14 Jan 2016 18:08:43 +0000 (UTC)<br>
From: Barbara Geller via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
Subject: Re: [cfe-dev] Open Clang Project : Document Generation tool<br>
with Clang<br>
Message-ID: <<a href="mailto:loom.20160114T185649-198@post.gmane.org">loom.20160114T185649-198@post.gmane.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
vivek pandya via cfe-dev <cfe-dev@...> writes:<br>
<br>
> Hello,<br>
> I have read about this open project on clang open project page.<br>
> What would be the advantage of using clang libs to implement doxygen like<br>
> tool ? I mean is there any use-case that are not implemented in doxygen but<br>
> with clang it can be implemented. Could some one explain this in a bit<br>
detail ?<br>
> I am currently experimenting with libClang to generate documents from<br>
> Objective-C (via comments like doxygen ) but my hunch is that generating<br>
> docs for C++ would be more difficult. <br>
> Sincerely,<br>
><br>
><br>
> Vivek Pandya<br>
> P.S : I would like to apply for this project in GSoC 2016. How important<br>
> is it for clang community.<br>
<br>
<br>
We are currently in the process of integrating libclang with DoxyPress for<br>
C++ parsing in lieu of the current lex based parser. We are very interested<br>
in having other developers participate in this process.<br>
<br>
If you or anyone else would like to work with us directly or through GSoC<br>
2016 we would be very interested.<br></blockquote><div>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. <br></div><div>I have seen your Cpp con video and I think you are planning to share the code on <a href="http://github.com">github.com</a> </div><div>- Vivek</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Barbara<br>
DoxyPress Co-founder<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 103, Issue 41<br>
****************************************<br>
</blockquote></div><br></div></div>