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

[Manuel Klimek]

On Fri, Aug 9, 2013 at 8:02 AM, Barrie Slaymaker <barries at slaysys.com>wrote:

> 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 ;)


> 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 ;)

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

Cheers,
/Manuel


>
> Thanks,
>
> Barrie
> ______________________________**_________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130810/37b367a3/attachment.html>