Future of refactorings

[Maciej Poleski]

Hi

At least both of us see that not everything is as fluent as it should be. I was a bit misled by lots of blogs describing libTooling as a universal basis for refactoring tools. It turns out that not everything is as simple as it looked like.

Ideas I had at the beginning are not best fit for capabilities we have here. We should think again about possibilities being aware that e.g. ability to connect information between TUs is limited. "local refactorings" seems good, but what does it mean?

I was thinking about possible implementation of de-inliner (header -> implementation). What is worrying is that when we take AST node, we are unable to make modifications and serialize it back to source code. We can only take its source (range to be precise). Then we work with text and have no further help with it.
Of course we can "cut" implementation from header (and leave semicolon instead), get implementation file (using buddy feature from KDevelop), prepare new declaration here somehow (traversing AST tree up to root and collecting names of nested DeclContexts...) and put previously cut code here. Very dumb, very context-insensitive, lack of any semantic interpretation - we are working on text. If implementation depends somehow on context of header (namespaces, ...) we are missing this dependency. I'm not sure if such functionality is satisfying for us.

Give more examples of tools which may be interesting. We should try to maximize effect (usefulness). What other refactorings can be useful for us (programmers)? Let's try to prepare some set of interesting tools. We can then order them depending on do-ability, usefulness, other traits. I'm a bit sucked from ideas for now, as my ideas burned on libTooling(/Clang compiler) API.

PS
What is very noticeable for me is that libTooling is a great tool to introspect existing code. I can't imagine other approach yielding so precise information about code. Maybe it is not the best foundation for general purpose refactorings (as opposed to "special purpose" refactorings), but it has extreme capabilities to extract information. I have feeling that libTooling could ultimately power the whole C++ IDE, with very precise information about code. Even tool consisting of only two parts: text editor and Clang could be very powerful.

PPS
Do You know how libTooling operates? Tool based on libTooling is, in simplified, one pass through C++ AST. Compiler in general (not including parsing, etc) is a set of AST visitors which do appropriate transformations of AST (like binding names with declarations, type-checking, ...). When we write tool what we make is an AST visitor. We get C++ AST (created by compiler) and run one more action on it - our AST visitor (but tree we see is read-only). The whole process is very similar to compilation. It also means that time is proportional to compilation time.

Best Regards
Maciej Poleski