<div dir="ltr">On Fri, Aug 9, 2013 at 8:02 AM, Barrie Slaymaker <span dir="ltr"><<a href="mailto:barries@slaysys.com" target="_blank">barries@slaysys.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>I don't think your CPU use is at all visible here - you're parsing C++ in between ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I /think/ what I'd like to do is either:<br>
<br>
    a) construct one SourceManager and configure it into both the Rewriter<br>
    and the RefactoringTool (which would  pass it to MatchFinder),  or<br>
<br>
    b) get a reference to the RefactoringTool's SourceManager that the tooling<br>
    front-end class creates (i.e. the one that gets passed to MatchFinder via<br>
    an ASTContext, if I read the code correctly) and then use that instance to<br>
    construct the Rewriter.<br>
<br>
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.<br>

<br>
Or is this just the wrong way to think about using these classes?<br></blockquote><div><br></div><div>The first thing to do would be to allow a multiple Compiler instances to share the same SourceManager, as that's what RefactoringTool uses.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>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 ;)</div>
<div><br></div><div>Also, I'd definitely work from clang's head, especially if you want to learn - clang is a fast-moving target.</div><div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Thanks,<br>
<br>
Barrie<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>