Sharing SourceManager between a RefactoringTool+MatchFinder front-end and a Rewriter?

Clang Frontend
#1

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

#2

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?

No. SourceManagers are inherently "TU-specific", have the concept of a
"main source file", etc. To support this would require some major redesign
iiuc. I'd have preferred the design if this was possible, for what it's
worth; I also don't remember all the problems I've run into, but in my
opinion it is clearly not feasible / worth the engineering cost.

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 don't think your CPU use is at all visible here - you're parsing C++ in
between :wink:

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?

The first thing to do would be to allow a multiple Compiler instances to
share the same SourceManager, as that's what RefactoringTool uses.

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.

So, I appreciate the input / idea, but I think there's currently not much
we can (or even should) do regarding the use of the source manager. If you
want to contribute, one great way to do that would be to help the
cpp11-migrate effort :wink:

Also, I'd definitely work from clang's head, especially if you want to
learn - clang is a fast-moving target.

Cheers,
/Manuel