[cfe-dev] GSoC project ideas
Vane, Edwin
edwin.vane at intel.com
Mon Apr 29 07:16:18 PDT 2013
Comments below.
> -----Original Message-----
> From: Guillaume Papin [mailto:guillaume.papin at epitech.eu]
> Sent: Sunday, April 28, 2013 9:13 PM
> To: Vane, Edwin
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] GSoC project ideas
>
> 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.
>
I agree. It's not completely trivial due to semantic differences between auto_ptr and unique_ptr (e.g. no destructive copy in unique_ptr) but should be a good first big project.
> 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.
>
A test for determining if the functionality of one constructor is completely subsumed by another would be really difficult to do. I'm not sure the benefit of a few less lines of code and some improved maintainability is really worth it. There is the common workaround of having constructors call init() functions that might be easier to handle but still, I think there are more useful things to focus on first.
> 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).
>
Also questionable implementation/benefit ratio. You'd have to ensure every member variable is initialized the same way by every constructor. If you detect such a case, that would mean removing all the existing initializations and adding the in-class initialization. All that's left is to hope the user didn't mind making some vars initialized by constructors and some by the in-class initializers.
> 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.
>
Definitely something we'd like to add to the migrator but requires some design first. User interactivity should be implemented in such a way that the actual user interface doesn't matter. That way one could write a plugin for an editor/IDE or just have a simple command-line interface. This implies some sort of library interface for cpp11-migrate and cpp11-migrate itself then turns into a library. LibFormat and clang-format have the same relationship. I'm not sure if this much design work is suitable to a GSoC project.
> 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.
>
This is kinda cool. It's certainly not much work right now since there are only a handful of transforms. It'd be a slightly nicer way than just saying --all-transforms (if such an option existed) especially for people out there migrating code that's tied to a particular compiler version.
Remembering the discussion about C++11 on llvm-dev a while back, maybe you could even specify a list of compilers to this flag and the common subset of supported features is applied :)
> 6 Integrating LibFormat
> ========================
>
> In order to format correctly inserted code.
>
Would definitely be nice. The transforms don't do too much to mangle code right now but any that use the TypePrinter to print out types will cause the 'const' to go on the wrong side of the type specifier according to most styles. (i.e. const MyType *A => MyType const A*). I don't think LibFormat handles const locations though yet, probably for the same reason the transforms are limited in dealing with const qualifiers currently: clang doesn't provide enough TypeLoc info.
> 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).
>
Could be useful. Also in this category would be use of stl_container::emplace() functions. You'll have to be very, very careful about semantics though.
> 8 Generate a diff of the changes
> =================================
>
> Add an option to print a diff of the modifications against the
> original source file.
>
Could be useful as a kind of 'dry-run' mode where changes are not actually made but one could find out how many and what sort of changes were made.
> 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)
Someone once suggested to me looking for:
Std::vector<int> A;
A.push_back(a);
A.push_back(b);
...
A.push_back(z);
And replacing with
Std::vector<int> A = {a,b,...,z};
I'm not entirely sure this is worth the effort. That is, how often is a vector initialization done this way? I'm not aware of other use cases right now.
> - tr1 replacements. Doing everything might not be possible but at
> least some would be useful such as: unordered_map, smart
> pointers, function<> & bind(), tuple.
This one in particular is high priority. I think pretty much everything in TR1 except the extra math functions is in C++11.
> - 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)
I agree.
> - and (much) more...
>
Another option could be looking at additions to STL for C++11 and making changes based on those additions. I mentioned emplace earlier. Another option could be looking for nested calls to std::max or std::min to do an N-wise horizontal max/min op: std::max(std::max(a,b), std::max(c,d)) => std::max({a,b,c,d}); Again, not sure how useful this particular case is. Another suggestion was replacing use of C arrays with std::array. I haven't looked into the implications of this myself though. Yet another option is something done by the remove-cstr tool in clang-tools-extra. C++11 allows you to create std::fstreams with a std::string directly now instead of calling std::string::c_str().
>
> "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=relevanc
> >>>e+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