[cfe-dev] GSoC project ideas
sergey.shambir.auto at gmail.com
Sat Apr 13 19:05:09 PDT 2013
Are you interested in improving C++ code completion? QtCreator clang
plugin revealed ~12 issues in this area. Fixing it probably will be
enough for GSoC. On the on hand, I have no idea where you can find
mentor for this project. On the other hand, I can provide additional
information for each bug when needed. I hope you will find some feature
requests collected in other clang-based plugins. Maybe Dmitri Gribenko
can tell about situation with vim-complete.
If you want to make some patches before GSOC, check this:
The most annoying bug is: http://llvm.org/bugs/show_bug.cgi?id=15745 (it
can take much time to fix)
13.04.2013 07:02, Guillaume Papin пишет:
> 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
> 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
> 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:
> 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.
More information about the cfe-dev