<div dir="ltr">If you only care about C: Long ago, clang's Parser talked to an abstract "Action" interface, and Sema was only one possible implementation of it. There used to be also a ParserPrintActions that could be requested via -parse-print-callbacks. This got deleted in <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100719/032534.html">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100719/032534.html</a> , so if you check out anything older than r109391 you can play with that. It might do what you want.<div><br></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">C++ made it necessary to get rid of this separation, <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Action.h?view=log&pathrev=112243">http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Action.h?view=log&pathrev=112243</a> shows how the Action class slowly whittled away, finally getting deleted in r112244 with a peculiar commit message.</blockquote></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 8:25 PM, Raghavan <span dir="ltr"><<a href="mailto:raghavan97@yahoo.co.in" target="_blank">raghavan97@yahoo.co.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I just wanted to see how the recursive descent parser functions get activated. This is more for showing students how a recursive descent parser works in a production compiler rather than checking correctness.<br>
<br>
I had done a similar thing for the 'cc1' in gcc by compiling 'cc1' using the '-finstrument-functions' option. This gives me control each time a function gets called or exits. Using that I was able to generate something like this.<br>
<br>
<br>
<br>
# The input C source file<br>
$ cat -n test3.c<br>
     1  int var1,var2;<br>
<br>
# The output from my instrumented 'cc1' compiler when I compile the above file.<br>
<br>
{ enter c_parser_translation_unit<br>
   { enter c_parser_external_declaration<br>
      { enter c_parser_declaration_or_fndef<br>
         { enter c_parser_declspecs<br>
            { enter c_parser_consume_token<br>
               Token No:1 Lexeme:'int' Type:CPP_NAME<br>
            } exit c_parser_consume_token<br>
         } exit c_parser_declspecs<br>
         { enter c_parser_declarator<br>
            { enter c_parser_direct_declarator<br>
               { enter c_parser_consume_token<br>
                  Token No:2 Lexeme:'var1' Type:CPP_NAME<br>
               } exit c_parser_consume_token<br>
               { enter c_parser_direct_declarator_inner<br>
               } exit c_parser_direct_declarator_inner<br>
            } exit c_parser_direct_declarator<br>
         } exit c_parser_declarator<br>
         { enter c_parser_consume_token<br>
            Token No:3 Lexeme:',' Type:CPP_COMMA<br>
         } exit c_parser_consume_token<br>
         { enter c_parser_declarator<br>
            { enter c_parser_direct_declarator<br>
               { enter c_parser_consume_token<br>
                  Token No:4 Lexeme:'var2' Type:CPP_NAME<br>
               } exit c_parser_consume_token<br>
               { enter c_parser_direct_declarator_inner<br>
               } exit c_parser_direct_declarator_inner<br>
            } exit c_parser_direct_declarator<br>
         } exit c_parser_declarator<br>
         { enter c_parser_consume_token<br>
            Token No:5 Lexeme:';' Type:CPP_SEMICOLO<br>
         } exit c_parser_consume_token<br>
      } exit c_parser_declaration_or_fndef<br>
   } exit c_parser_external_declaration<br>
} exit c_parser_translation_unit<br>
<br>
It maps closely with the following productions from the standard at<br>
<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" target="_blank">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf</a>. The section numbers given in the Table 3 1 correspond to the sections in the same document.<br>
<br>
<br>
<br>
translation-unit        :       external-declaration    6.9.1<br>
external-declaration    :       declaration     6.9.1<br>
external-declaration    :       function-definition     6.9.1<br>
declaration     :       declaration-specifiers init-declarator-listopt ;        6.7.1<br>
declaration-specifiers  :       type-specifier declaration-specifiersopt        6.7.1<br>
type-specifier  :       int     6.7.2<br>
init-declarator-list    :       init-declarator 6.7.1<br>
        :       init-declarator-list , init-declarator  6.7.1<br>
init-declarator         :       declarator      6.7.1<br>
declarator                      :       pointeropt direct-declarator    6.7.6<br>
direct-declarator       :       identifier      6.7.6<br>
<br>
<br>
<br>
Thanks.<br>
<br>
Bye,<br>
Raghavan V<br>
<br>
<br>
<br>
From: Nikola Smiljanic [mailto:<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>]<br>
Sent: Thursday, September 25, 2014 3:33 AM<br>
To: Daniel Dilts<br>
Cc: Raghavan; cfe-dev Developers<br>
Subject: Re: [cfe-dev] Recursive Descent Parser<br>
<div class="HOEnZb"><div class="h5"><br>
I'm not sure what Raghvan is trying to achieve but I don't think the graph would be very helpful. Grammar productions are available in Annex A of the standard (if that's all he's after) but AFAIK clang's parser doesn't map 1:1 to them.<br>
<br>
On Thu, Sep 25, 2014 at 7:47 AM, Daniel Dilts <<a href="mailto:diltsman@gmail.com">diltsman@gmail.com</a>> wrote:<br>
I suppose that someone could write a utility using Clang to dump the call graph starting at the base rule.<br>
<br>
<br>
On Wed, Sep 24, 2014 at 2:31 PM, Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>> wrote:<br>
I don't think there is. Have a look at clang::ParseAST. it keeps track of the callstack in case of crash. It also keeps track of some statistics but I think that's all there is.<br>
<br>
On Sun, Sep 21, 2014 at 9:55 AM, Raghavan <<a href="mailto:raghavan97@yahoo.co.in">raghavan97@yahoo.co.in</a>> wrote:<br>
Hi,<br>
<br>
I am a newbie to clang and LLVM.<br>
<br>
I realize that the clang uses Recursive descent parsing for compiling a c file.<br>
<br>
I was wondering, if there is any way to print the production rules or any kind of parser related details during the parsing of a C file by clang.<br>
<br>
<br>
Thanks.<br>
<br>
Bye,<br>
Raghavan V<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>