<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 September 2016 at 14:55, Eric Bayer <span dir="ltr"><<a href="mailto:ebayer@vmware.com" target="_blank">ebayer@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <div>Thanks Alex,<br>
      <br>
      That gets me mostly there.  Pardon if that is a dumb question, but
      I'm not sure how I go from a SourceLocation to a Token.  I have
      not worked at all in the preprocessor levels before.</div></div></blockquote><div><br></div><div>Something like this should work:</div><div><br></div><div><div>    StringRef getToken(SourceLocation BeginLoc, SourceManager &SM, LangOptions &LangOpts) {</div><div>      const SourceLocation EndLoc = Lexer::getLocForEndOfToken(BeginLoc, 0, SM, LangOpts);</div><div>      return Lexer::getSourceText(CharSourceRange::getTokenRange(BeginLoc, EndLoc), SM, LangOpts);</div><div>    }</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div><span class="gmail-HOEnZb"><font color="#888888"><br>
      <br>
         -Eric<br>
      </font></span><br>
      PS - Is there a good page somewhere that outlines how these layers
      hang together?  Just don't wanna take up time if there's docs
      somewhere.</div></div></blockquote><div><br></div><div>I think that the “Clang” CFE Internals Manual (<a href="http://clang.llvm.org/docs/InternalsManual.html">http://clang.llvm.org/docs/InternalsManual.html</a>) might give you some of the information that you're looking for.</div><div><br></div><div>Alex</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div><div><div class="gmail-h5"><br>
      <br>
      On 9/23/2016 3:33 PM, Alex L wrote:<br>
    </div></div></div><div><div class="gmail-h5">
    <blockquote type="cite">
      
      <div dir="ltr">Hi Eric,
        <div><br>
        </div>
        <div>Yes, you can iterate the source range of a declaration like
          a function. But I don't think you need to, as you can iterate
          macro expansions and check if they were expanded inside the
          source range of the function. The following piece of code
          illustrates this approach (assuming you have a declaration
          Decl and a source manager reference SM): </div>
        <div><br>
        </div>
        <div>  SourceLocation Start = Decl->getLocStart();</div>
        <div>  SourceLocation End = Decl->getLocEnd();</div>
        <div>  for (unsigned I = 0, E = SM.local_sloc_entry_size(); I !=
          E; ++I) {</div>
        <div>    const SrcMgr::SLocEntry &Entry =
          SM.getLocalSLocEntry(I);</div>
        <div>    if (Entry.isExpansion() &&
          Entry.getExpansion().<wbr>isMacroBodyExpansion()) {</div>
        <div>      SourceLocation Loc =
          Entry.getExpansion().<wbr>getExpansionLocStart();</div>
        <div>      if (Start < Loc && Loc < End) {</div>
        <div>         // This Macro expansion is inside the body of the
          function (Decl).</div>
        <div>      }</div>
        <div>    }</div>
        <div>  }</div>
        <div>     </div>
        <div>You can get the name of the macro that is expanded inside a
          function by looking at the first token that's at the location
          'Loc' i.e. at the starting location of the expansion.</div>
        <div><br>
        </div>
        <div>I hope that helps,</div>
        <div>Alex</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 23 September 2016 at 14:20, Eric
          Bayer via cfe-dev <span dir="ltr">
            <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
            Hi,<br>
            <br>
            I have a project that I've been working on to determine
            dependencies in code and mock/stub them.  Mostly I'm using a
            recursive visitor to datamine these things.  I would really
            like to be able to figure out what macros are used in a
            function as well (or SourceRange would be even more
            helpful.)   Just to be clear I'm doing this as a clang
            frontend plugin (currently stopping at syntax check).  I
            know that I can capture these PPCallbacks and store away
            their SourceLocations etc during preprocessing, but based on
            what is done in error messages I would imagine that the
            information is there somewhere already... I'd rather not
            reinvent the wheel if something else will work already.<br>
            <br>
            For example:<br>
            <br>
            #define BAR "%s"<br>
            #define FOO(x) printf( BAR, x )<br>
            #define DOY 3<br>
            void func1() {<br>
                const char *lvar="func1";<br>
                FOO(lvar);<br>
            }<br>
            void func2() {<br>
                printf("%d", DOY);<br>
            }<br>
            <br>
            What I want to be able to do is isolate func1() and
            determine that FOO and BAR were both used and what macro
            they were pointing to at the time they were used.  What I'm
            hoping is that there is way to iterate the SourceRange to
            find where the text pieces came from (with enough info to
            know what the macro name/definition was).  I didn't see an
            obvious way to do this.  Then again, maybe I'm going down
            the wrong path and there's an entirely easier direction?<br>
            <br>
            Anyhow, even some hints in the right direction would be
            greatly appreciated.<br>
            <br>
            Thanks in advance,<br>
            <br>
               -Eric<br>
            <br>
            <br>
            <br>
            ______________________________<wbr>_________________<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="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=JUV4JPCePpFuWnRnH3TEko8ht33mtVYPAwDFFDOf8Jo&m=gzwiz0TzfEAolcm8zjqP9fh9BmiSJ_RzO2awDH0QMsc&s=lwgwDT0RAiR562A5bU82lmnf09VyqtQCL-vRd1p16QA&e=" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div></div></div>

</blockquote></div><br></div></div>