<div dir="ltr">Manuel,<div><br></div><div>Thank you for the quick reply.</div><div><br></div><div>I am following exactly implementation design you mentioned.</div><div>All information, apart from the transformations themselves which are communicated via a temporary file, are store in global data structures.<br><br>My question is more on the reasons why an ASTFrontendAction object must be owned by a ScopedToolAction from the moment the ToolAction is invocation until its end.<br>Which errors might occur if I do not delete each ASTFrontendAction and reuse them across multiple invocations?</div><div><br></div><div>Maybe I should use a vector of FrontendActionFactory objects instead of ASTFrontendAction?</div><div><br>Att.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 23, 2018 at 5:52 AM Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FrontendActions you return are owned by the compiler; the idea is to store any data you need across multiple FrontendActions in a different data structure, and have hand pointers to those through to your FA.</div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Thu, Mar 22, 2018 at 3:23 PM João Paulo Labegalini de Carvalho via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>My name is João (some kind of brazilian version for John) and I am implementing a tool based using the libTooling framework. The goal of the tool is to performe Source-To-Source code transformations for later analysis/instrumentation through a LLVM Pass. The transformations will basically "mark" the start and end of OMPParallelFor loop bodies. The LLVM Pass will instrument all load/store instructions and hand their pointer operand to my runtime library. The runtime will attempt to detect loop-carried dependencies.</div><div><br></div><div>Each transformation must be able to see the result of previous transformations, therefore I have implemented a slightly modified version of the ClangTool. I am attaching the source code containing the run method of my custom ClangTool class (a.k.a. CheckerTool).<br></div><div><br></div><div>Right now my tool is able to successfully run multiple ASTFrontendAction actions over a single source file. However, as soon as ToolInvocation finishes processing a file, my custom ASTFrontendAction is destroyed. By inspecting the code of ToolInvocation::runInvocation method at lib/Tooling/Tooling.cpp I have found the culprit. The ToolInvocation object takes ownership of my ASTFrontendAction through a std::unique_ptr stored in the object ScopedToolAction. Looking through the history of the Tooling.cpp in the llvm/clang project on github I have found the commit which introduced such behavior (<a href="https://github.com/llvm-mirror/clang/commit/14a192435425af39e7f32b6e71613f9357e995f7#diff-bf9ab6da20a9d03d965b034c8c30a010" target="_blank">https://github.com/llvm-mirror/clang/commit/14a192435425af39e7f32b6e71613f9357e995f7#diff-bf9ab6da20a9d03d965b034c8c30a010</a>).</div><div><br></div><div>The comment associated with such change tries to explain why it is necessary to delete the ToolAction as soon as the invocation ends, however I am failing to understand it. I would greatly appreciate if anyone of you, far more educated than myself on the inner workings of clang, could explain to me the mentioned comment ("ToolAction can have lifetime requirements for Compiler or its members.....").</div><div><br></div><div>I was able to accomplish my goal by replacing the std:unique_ptr by a "conventional" pointer in the ToolInvocation::runInvocation method. Nonetheless, I fear for the completeness of my work-around.</div><div><br></div><div>Best regards,</div></div>-- <br><div dir="ltr" class="m_-1979888151226351564m_1689977289217656786gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px">João Paulo L. de Carvalho<br>Computer Science |  IC-UNICAMP | Campinas , SP - Brazil</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><a href="mailto:jaopaulolc@gmail.com" target="_blank">jaopaulolc@gmail.com</a></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><a href="mailto:joao.carvalho@ic.unicamp.br" target="_blank">joao.carvalho@ic.unicamp.br</a></div></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px">João Paulo L. de Carvalho<br>Computer Science |  IC-UNICAMP | Campinas , SP - Brazil</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><a href="mailto:jaopaulolc@gmail.com" target="_blank">jaopaulolc@gmail.com</a></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><a href="mailto:joao.carvalho@ic.unicamp.br" target="_blank">joao.carvalho@ic.unicamp.br</a></div></div></div>