[cfe-dev] Sharing SourceManager between a RefactoringTool+MatchFinder front-end and a Rewriter?

[Barrie Slaymaker]

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.

Thanks,

Barrie