Is there a convenient way to have the front-end (a MatchFinder in this case) and back-end (a Rewriter) share a SourceManager and/or FileManager?
This would allow the application to read each source files only once and also avoid the memory and CPU overhead of having to getDecomposedLoc() relative to MatchFinder's SourceManager (like Replacement does); it would allow MatchResult.SourceLocation to be passed to Rewriter methods. Neither optimization is critical; this is a learning exercise in how to reduce the redundancy here, the app I'm writing works fine as-is.
I /think/ what I'd like to do is either:
a) construct one SourceManager and configure it into both the Rewriter
and the RefactoringTool (which would pass it to MatchFinder), or
b) get a reference to the RefactoringTool's SourceManager that the tooling
front-end class creates (i.e. the one that gets passed to MatchFinder via
an ASTContext, if I read the code correctly) and then use that instance to
construct the Rewriter.
In both cases, the SourceManager instance needs to live until after RefactoringTool.run() returns or, failing that, until it calls an EndOfSourceFileCallback.run(). I'm not using an EndOfSourceFileCallback now, but could.
Or is this just the wrong way to think about using these classes?
Context: I'm currently working with Clang 3.3, though I could easily move to or 3.4-to-be. This a learning question--I'm a newcomer to clang::tooling:: (which I'm really enjoying by the way--this thing's amazing) and am writing a tiny source-to-source C rewriting tool to learn about clang::tooling:: and, if it works, to make a tool I'd like to have had on some recent projects.