[cfe-dev] GSoC project ideas

Vane, Edwin edwin.vane at intel.com
Tue Apr 23 07:39:01 PDT 2013


Not sure if you were expecting a response about the two proposals thing. I'm afraid I'm not sure what to do in this case. You can get advice about this from the LLVM GSoC coordinator on the llvm-dev mailing list. Or unless somebody here pipes up.

-----Original Message-----
From: Guillaume Papin [mailto:guillaume.papin at epitech.eu] 
Sent: Thursday, April 18, 2013 7:38 PM
To: Vane, Edwin
Cc: cfe-dev at cs.uiuc.edu 
Subject: RE: [cfe-dev] GSoC project ideas

Thank you for the follow-up, it's a good news. I will do my best fort the proposal (and probably asks some questions in the process).

>From Douglas Gregor comment, I can eliminate working on Modules or a Doxygen-like tool.
Improving libclang still seems to be a good projects. Working on cpp11-migrate interest me a bit more than improving libclang, I'm not sure if I should write 2 proposals in case working on cpp11-migrate wouldn't be accepted independent from me.

"Vane, Edwin" <edwin.vane at intel.com> wrote:

>Just a follow-up. Now I'm more familiar with what's involved with GSoC mentoring I don't see any reason I couldn't be a mentor assuming you choose cpp11-migrate and your application is accepted:)
>
>-----Original Message-----
>From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Vane, Edwin
>Sent: Wednesday, April 17, 2013 10:12 AM
>To: Guillaume Papin
>Cc: cfe-dev at cs.uiuc.edu 
>Subject: Re: [cfe-dev] GSoC project ideas
>
>You're right that auto_ptr replacement is probably the easier of the transforms you listed. It's not completely trivial due to the semantic differences between auto_ptr and unique_ptr (the lack of destructive copy in the latter for example) but it would be a good place to start I think. Converting tr1->std would require not only changing types but also changing #includes which is something the migrator doesn't look at for anything else right now.
>
>I could be a mentor but I have to read about what's involved. I have cursory permission from my manager to help out but I need to find out more details.
>
>-----Original Message-----
>From: Guillaume Papin [mailto:guillaume.papin at epitech.eu] 
>Sent: Wednesday, April 17, 2013 7:46 AM
>To: Vane, Edwin
>Cc: cfe-dev at cs.uiuc.edu 
>Subject: RE: [cfe-dev] GSoC project ideas
>
>Thank you for the information, along with the blog post this give me a good overview of the project. Working on this project is definitely something of high interest to me.
>
>I will select a subset of the improvements you already have reported for my proposal. ATM it's seems to be a bit difficult to estimate the time of those tasks (while I have a rough idea for 'auto_ptr replacement', 'tr1 suppression' or 'add the passing by value when move constructor is available on the stored type ' seem more difficult).
>
>Do you think it will be difficult to find a mentor for such project?
>
>"Vane, Edwin" <edwin.vane at intel.com> wrote:
>
>>Hey Guillaume,
>>
>>Being a new project, cpp11-migrate has a ton of things to work on. We've been trying to log bugs in bugzilla as well as our internal JIRA but I'm afraid most of our ideas for improvements to cpp11-migrate are in our internal JIRA instance only. You saw a few new transforms listed already: tr1 removal and making use of existing move constructors. Also planned is a transform to replace use of the deprecated auto_ptr class with unique_ptr. You might find today's LLVM blog posting on the migrator interesting too: http://blog.llvm.org/2013/04/status-of-c11-migrator.html.
>>
>>There are a few bugs available too:
>>
>>http://llvm.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=clang-tools-extra&content=
>>
>>If you're keen on learning and using the new features in C++11 or are interested learning the C++ language at the level of the specification your help would be most welcome.
>>
>>-----Original Message-----
>>From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Guillaume Papin
>>Sent: Friday, April 12, 2013 11:03 PM
>>To: cfe-dev at cs.uiuc.edu
>>Subject: [cfe-dev] GSoC project ideas
>>
>>Hello,
>>
>>I'm currently trying to define a project proposal for the Google Summer of Code. I'm looking for a project that will be at the same time valuable to Clang and appealing to me. I am mainly interested by the tooling infrastructure (enhancements to LibClang, LibTooling or work in extra/).
>>
>>After some digging, I have found various options that I would like to discuss with the community in order to find the best match in terms of usefulness and "fitability" (~12 weeks).
>>
>>
>>-- Modules --
>>
>>I stumbled upon the modularize project (in extra/) and the Module.rst document. The section "Future Directions" caught my attention.
>>Available here: http://clang.llvm.org/docs/Modules.html#future-directions
>>
>>**Improve modularize** interests me but I'm not sure what "better UI"
>>and "assistant mode" imply. If it's about writing a GUI application I am not sure it is what I'm looking for the GSoC but maybe it's about enhanced program options, configuration files and an interactive mode? I don't know yet how convoluted can be the detection of problems. Might-it be a fit for the GSoC itself?
>>
>>I'm also interested by **Detect unused module imports** and **Fix-Its for missing imports** which I think can fit together under the same project.
>>
>>For the **C++ Support**, this is really unclear to me today what are the implications of such project. What needs to be done and how.
>>
>>
>>-- Doxygen like tool --
>>
>>The open Clang projects page has an entry: "Implement a tool to generate code documentation". I have the feeling that everything that is needed is already available in the LibClang comment API. What is left is mainly the generation of the website (or similar). If I am not mistaken then I am too interested by this project for the GSoC.
>>
>>
>>-- cpp11-migrate --
>>
>>I saw this project in extra/ that I find interesting. One idea of improvement I read is "add the passing by value when move constructor is available on the stored type".
>>
>>And some other ideas are also available here:
>>http://clang.llvm.org/docs/ClangTools.html#ideas-for-new-tools
>>
>>Such as:
>>- Convert member functions begin()/end() to their non-member counterpart.
>>- Replace tr1 by the C++11 version (drop tr1 namespace and tr1/
>>  include prefix for example).
>>
>>
>>-- Compilation Database --
>>
>>I saw a few times on the mailing list the idea of adding an option to Clang to generate a compile_commands.json. I think only CMake and Ninja offer such support for now. Clang is supported by more build systems, having this option could increase the number of projects "Tooling-friendly". The implementation will have to deal with parallel compilation jobs but I don't think it's too difficult. Alone this task is certainly too short for the GSoC.
>>
>>
>>
>>To finish a few words about me. I'm Guillaume Papin, French student (but actually doing the 1st year of my Master in Sweden). I chose Clang for the GSoC because it's a project I follow for some time now (since 2011).
>>I regularly check the mailing list and I'm in love with the code base who is very clean IMHO (not only Clang but more generally LLVM). I'm working on an Emacs package that provides C/C++ completion using LibClang (still needs a lot of work): https://github.com/Sarcasm/irony-mode.
>>
>>Thank you.
>>--
>>Guillaume Papin
>>
>>_______________________________________________
>>cfe-dev mailing list
>>cfe-dev at cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>_______________________________________________
>cfe-dev mailing list
>cfe-dev at cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>




More information about the cfe-dev mailing list