[cfe-dev] clang-refactoring tool proposal
Milian Wolff via cfe-dev
cfe-dev at lists.llvm.org
Wed Aug 10 03:59:34 PDT 2016
On Mittwoch, 10. August 2016 00:06:46 CEST Ben Jackson via cfe-dev wrote:
> First, I think clang-refactor is a great idea and a great point of focus for
> really useful tools.
> > My proposed solution is to create clang-refactor tool, which would be an
> > “umbrella” for other refactoring modules. A prototype of clang-refactor
> > would merge clang-rename inside of it and other modules and refactorings
> > would be added later.
> > A properly designed clang-refactor tool would be able to process multiple
> > Translation Units, which is crucial for all mentioned refactoring.
> As a maintainer of a code comprehension tool which uses libclang, it would
> be really useful if such a refactoring ability was exposed via the
> higher-level APIs. We’d *love* to have IDE-like refactoring for C/C++/etc.
> in the tool, and I’m sure our users would too :).
> One of the challenges we have with clang-rename, clang-include-fixer etc. is
> that they are difficult to integrate with existing applications which use
> libclang. Or perhaps I should say, they require orthogonal integration -
> currently to integrate these tools, even though I have successfully
> generated a TU/AST etc., I have to shell out to a binary which users may or
> may not have installed.
> I know that is probably complex to deliver in practice, and I understand
> that the maintainers may have different opinions on the scope of libclang
> (or even the scope of this discussion!), but I wanted to throw the idea out
> there, in case there is appetite. Certainly, I would be super excited to
> integrate these tools into ycmd/YouCompleteMe. I don’t doubt others would
> similarly benefit.
I can only second the above. KDevelop is in exactly the same position, and I
bet lots of other tools out there are as well. Just think of the potential
time that can be saved by handing in an existing TU instead of having to parse
that yet again.
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the cfe-dev