I have two ideas revolving around Clang that I’d like to propose for the Google Summer of Code. Because I’m equally interested in both ideas, I’m posting brief descriptions of them here, in the hope that if one of them is received better than the other then I could save time by only proposing one. But if neither one is clearly preferred then I will formally propose both.
I am fascinated by the videos I’ve watched of conference presentations about LibTooling. It can make large scale refactorings very easy. But at the small and medium scales, it seems like it would still be cheaper in many cases to do the refactoring by hand, because an automated tool to perform one specific refactoring would be unlikely to retain its usefulness after the refactoring is done. To reduce the cost of small scale LibTooling refactorings, I imagine a kind of rapid development tool for LibTooling refactorings, which would help a user to compose a LibTooling expression out of all the available primary and composite expressions. Whenever the expression is changed, the tool would present a preview of what the code would look like under the refactoring represented by the new expression. The user can gradually refine the expression and instantly see the effects of those refinements on the code, until the refactoring is exactly as she wants it. The deliverable would be a library or commandline tool which could be integrated into plugins for different IDEs, plus one or two example plugins for popular IDEs.
SWIG is a powerful and widely used tool for wrapping C and C++ APIs to make them available from within many different scripting languages. It has a built in C/C++ parser and customization is possible through language extensions. But in my opinion the SWIG codebase has unfortunately become poorly factored and difficult to adapt or extend. I propose a tool fulfilling broadly the same use cases as SWIG, but built upon LibClang, clean architecture, and modern C++. Customization could be provided by C++11 attributes. Of course achieving feature parity with SWIG in a single GSoC cycle would be laughably ambitious. But I think an achievable aim would be to support, say, classes at namespace scope, and functions and constants at namespace and class scope, simple function argument mapping, and one or two target scripting languages, and hope that the community can take that seed and continue to grow it.
I’ll be interested to see which, if any, of these ideas meet with your enthusiasm.
Thanks for reading,