[cfe-dev] GSoC project ideas
edwin.vane at intel.com
Mon Apr 15 06:28:03 PDT 2013
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:
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.
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
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/).
-- 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:
- 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.
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
More information about the cfe-dev