[cfe-dev] GSoC project ideas
Guillaume Papin
guillaume.papin at epitech.eu
Sun Apr 28 18:13:20 PDT 2013
I'm working on the proposal and would like to have your feedback about
the following plan regarding cpp11-migrate.
Tasks
=====
Table of Contents
=================
1 Transform to replace 'auto_ptr' by 'unique_ptr'
2 Transform for delegating constructors
3 Transform for non-static data member initializers
4 Add support for interactive actions
5 Default transformation profile
6 Integrating LibFormat
7 Transform to make use existing of move constructors
8 Generate a diff of the changes
9 Other incomplete ideas
1 Transform to replace 'auto_ptr' by 'unique_ptr'
==================================================
Seems like a good transform to start.
2 Transform for delegating constructors
========================================
A transform that can convert code such as:
struct A
{
int x;
A() : x(0) { }
A(int _x) : x(_x) { }
};
Into:
struct A
{
int x;
A() : A(0) { } // now use delegation
A(int _x) : x(_x) { }
};
This is a really trivial case here but I expect this transform to
be non-trivial to implement.
3 Transform for non-static data member initializers
====================================================
When one or more constructor initialize a member variable with
a value independant from the constructor arguments the
initialization can be placed in-class.
This might be beneficial when multiple constructors are duplicating
member initialization.
Note that this transform might easily leads to conflicts with the
previous transform (delegating constructors).
4 Add support for interactive actions
======================================
Some actions might need user interaction.
Example (maybe not the best one):
If some replacement code needs to introduce a new variable and
that the default identifier is already taken then we might want to
prompt the user for an alternative name.
Or simply to ask confirmation before a risky replacement.
5 Default transformation profile
=================================
Apply a list of transformation by default and allow different
profiles. By profile I'm talking about an option such as:
cpp11-migrate -target-profile=[clang-3.2|gcc-4.7|...] ...
This option will enable all known safe (low-risk/zero-risk)
transformations to the input files and are supported by the given
target.
This could allow incremental migration toward C++11. Let's say the
project has to support Clang 3.1 in a first place and later on the
minimum version switch to 3.2, they can re-run the tools with the
new profile.
6 Integrating LibFormat
========================
In order to format correctly inserted code.
7 Transform to make use existing of move constructors
======================================================
With move semantics added to the language and the standard library
being updated accordingly (move constructors added to many types),
it is now interesting to take an argument by value and then moving
it (as opposed to take by 'const &' and then copy).
8 Generate a diff of the changes
=================================
Add an option to print a diff of the modifications against the
original source file.
9 Other incomplete ideas
=========================
If the charge of the previous ideas is not sufficient for the
GSoC I'm confident there is more work to do.
- initializer_list and uniform initialization transforms (use
cases not identified yet)
- tr1 replacements. Doing everything might not be possible but at
least some would be useful such as: unordered_map, smart
pointers, function<> & bind(), tuple.
- fixing existing bugs (I think it's a good way to get around the
project before starting the GSoC to get acquainted with the
code)
- and (much) more...
"Vane, Edwin" <edwin.vane at intel.com> writes:
> 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
>>
--
Guillaume Papin
More information about the cfe-dev
mailing list