Home » Language IDEs » C / C++ IDE (CDT) » Can't skip AST preprocessor statements?
| Can't skip AST preprocessor statements? [message #145066] |
Wed, 11 May 2005 18:45  |
Eclipse User |
|
|
|
Using the CDT3.0M6, I subclassed CASTVisitor and am traversing the AST,
however, how do I disable 'visit'ing IASTPreprocessorStatements
(i.e.-skipping #include statements)? Which 'visit' method is it using to
go down this path? I see that IASTPreprocessorStatement is a subtype of
IASTNode, which I don't think there is a specific implementation of visit
for. I tried creating another visit method to maybe catch preprocessor
statements, however to no avail. Basically, I just need to get the AST of
an IASTTranslationUnit minus preprocessor statements. Please help!
Mike
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145409 is a reply to message #145066] |
Fri, 13 May 2005 11:32  |
| Eclipse User |
|
|
|
Hi Mike,
The ast tree that you are visiting does not have the preprocessor statements
embedded in it. It represents the post-processed code of the entire
translation unit as the parser saw it after the scanner. The
IASTPreprocessorStatements are available from
IASTTranslationUnit.getAllPreprocessorStatements, which simply returns a
list of the statements as the scanner saw them, they themselves are not
arranged in a tree. The include statements are also available in a seperate
tree structure through IASTTranslationUnit.getDependancyTree()
If you wanted to skip include files, you could probably do it in visit(
IASTDeclaration ) ( since the children of the tu are all declarations), and
just return PROCESS_SKIP if IASTNode.getContainingFileName() for that
declaration is not the file you are interested in.
-Andrew
"Mike" <mcabusao@afit.edu> wrote in message
news:09936605f63ea00e6143d4fa7ae87187$1@www.eclipse.org...
> Using the CDT3.0M6, I subclassed CASTVisitor and am traversing the AST,
> however, how do I disable 'visit'ing IASTPreprocessorStatements
> (i.e.-skipping #include statements)? Which 'visit' method is it using to
> go down this path? I see that IASTPreprocessorStatement is a subtype of
> IASTNode, which I don't think there is a specific implementation of visit
> for. I tried creating another visit method to maybe catch preprocessor
> statements, however to no avail. Basically, I just need to get the AST of
> an IASTTranslationUnit minus preprocessor statements. Please help!
>
> Mike
>
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145674 is a reply to message #145409] |
Wed, 18 May 2005 11:20 |
| Eclipse User |
|
|
|
Originally posted by: fliao2.yahoo.ca
I'm working on something that requires all the preprocessor statements,
but I'm using the old parser (which only returns macros and includes in
the callback, as far as I can tell), how would I go about doing that? As
an aside, what sort of effort would be required to switch over to the dom
parser? Are most of the interfaces/behaviour the same or will there be a
significant number of changes that will need to be made?
Felix
Andrew Niefer wrote:
> Hi Mike,
> The ast tree that you are visiting does not have the preprocessor statements
> embedded in it. It represents the post-processed code of the entire
> translation unit as the parser saw it after the scanner. The
> IASTPreprocessorStatements are available from
> IASTTranslationUnit.getAllPreprocessorStatements, which simply returns a
> list of the statements as the scanner saw them, they themselves are not
> arranged in a tree. The include statements are also available in a seperate
> tree structure through IASTTranslationUnit.getDependancyTree()
> If you wanted to skip include files, you could probably do it in visit(
> IASTDeclaration ) ( since the children of the tu are all declarations), and
> just return PROCESS_SKIP if IASTNode.getContainingFileName() for that
> declaration is not the file you are interested in.
> -Andrew
> "Mike" <mcabusao@afit.edu> wrote in message
> news:09936605f63ea00e6143d4fa7ae87187$1@www.eclipse.org...
>> Using the CDT3.0M6, I subclassed CASTVisitor and am traversing the AST,
>> however, how do I disable 'visit'ing IASTPreprocessorStatements
>> (i.e.-skipping #include statements)? Which 'visit' method is it using to
>> go down this path? I see that IASTPreprocessorStatement is a subtype of
>> IASTNode, which I don't think there is a specific implementation of visit
>> for. I tried creating another visit method to maybe catch preprocessor
>> statements, however to no avail. Basically, I just need to get the AST of
>> an IASTTranslationUnit minus preprocessor statements. Please help!
>>
>> Mike
>>
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145710 is a reply to message #145674] |
Thu, 19 May 2005 11:41 |
| Eclipse User |
|
|
|
To get all the preprocessor statements using the old parser, you will need
to extend Scanner2 and do something in the process* methods. If you have an
older version of Scanner2, look at the handlePP* methods.
The interfaces with the new parser are completely different. The old parser
interfaces were syntax and semantic information all in one and the callbacks
happened while we were parsing. The new parser interfaces are seperated
into syntactic and semantic components. The new parser doesn't have
callbacks, instead you get a fully built syntax tree after the parse is
complete. You then visit this tree and ask whatever names you are
interested to resolve themselves into a semantic binding.
A switch would generally involving implementing an ASTVisitor and in
visit( IASTName ) inspect the name and the result of
IASTName.resolveBinding() to see how whatever logic you used to have in the
callbacks applies.
-Andrew
"Felix" <fliao2@yahoo.ca> wrote in message
news:118fa16ad0db4734d85554b3eab450d9$1@www.eclipse.org...
> I'm working on something that requires all the preprocessor statements,
> but I'm using the old parser (which only returns macros and includes in
> the callback, as far as I can tell), how would I go about doing that? As
> an aside, what sort of effort would be required to switch over to the dom
> parser? Are most of the interfaces/behaviour the same or will there be a
> significant number of changes that will need to be made?
>
> Felix
>
> Andrew Niefer wrote:
>
> > Hi Mike,
> > The ast tree that you are visiting does not have the preprocessor
statements
> > embedded in it. It represents the post-processed code of the entire
> > translation unit as the parser saw it after the scanner. The
> > IASTPreprocessorStatements are available from
> > IASTTranslationUnit.getAllPreprocessorStatements, which simply returns a
> > list of the statements as the scanner saw them, they themselves are not
> > arranged in a tree. The include statements are also available in a
seperate
> > tree structure through IASTTranslationUnit.getDependancyTree()
>
> > If you wanted to skip include files, you could probably do it in visit(
> > IASTDeclaration ) ( since the children of the tu are all declarations),
and
> > just return PROCESS_SKIP if IASTNode.getContainingFileName() for that
> > declaration is not the file you are interested in.
>
> > -Andrew
>
> > "Mike" <mcabusao@afit.edu> wrote in message
> > news:09936605f63ea00e6143d4fa7ae87187$1@www.eclipse.org...
> >> Using the CDT3.0M6, I subclassed CASTVisitor and am traversing the AST,
> >> however, how do I disable 'visit'ing IASTPreprocessorStatements
> >> (i.e.-skipping #include statements)? Which 'visit' method is it using
to
> >> go down this path? I see that IASTPreprocessorStatement is a subtype of
> >> IASTNode, which I don't think there is a specific implementation of
visit
> >> for. I tried creating another visit method to maybe catch preprocessor
> >> statements, however to no avail. Basically, I just need to get the AST
of
> >> an IASTTranslationUnit minus preprocessor statements. Please help!
> >>
> >> Mike
> >>
>
>
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145729 is a reply to message #145710] |
Thu, 19 May 2005 12:15 |
| Eclipse User |
|
|
|
Originally posted by: fliao2.yahoo.ca
Thanks, but I'm having some trouble though. I've made a very simple file:
#if !defined(__MYHEADER_H__)
#define __MYHEADER_H__
#endif
Then I made a simple extension of Scanner2, something like:
public class MyScanner extends Scanner2
{
public MyScanner(...) {
super(...);
System.out.println("MyScanner");
}
protected void handlePPDirective(int pos) throws EndOfFileException {
System.out.println("MyScanner.handlePPDirective");
}
}
I then feed my file into my scanner/parser. I see the line "MyScanner" get
printed out, but I don't see "MyScanner.handlePPDirective". I've also
tried the same thing on the other handlePP* methods, but to no avail. Any
idea what I'm doing wrong?
Felix
Andrew Niefer wrote:
> To get all the preprocessor statements using the old parser, you will need
> to extend Scanner2 and do something in the process* methods. If you have an
> older version of Scanner2, look at the handlePP* methods.
> The interfaces with the new parser are completely different. The old parser
> interfaces were syntax and semantic information all in one and the callbacks
> happened while we were parsing. The new parser interfaces are seperated
> into syntactic and semantic components. The new parser doesn't have
> callbacks, instead you get a fully built syntax tree after the parse is
> complete. You then visit this tree and ask whatever names you are
> interested to resolve themselves into a semantic binding.
> A switch would generally involving implementing an ASTVisitor and in
> visit( IASTName ) inspect the name and the result of
> IASTName.resolveBinding() to see how whatever logic you used to have in the
> callbacks applies.
> -Andrew
> "Felix" <fliao2@yahoo.ca> wrote in message
> news:118fa16ad0db4734d85554b3eab450d9$1@www.eclipse.org...
>> I'm working on something that requires all the preprocessor statements,
>> but I'm using the old parser (which only returns macros and includes in
>> the callback, as far as I can tell), how would I go about doing that? As
>> an aside, what sort of effort would be required to switch over to the dom
>> parser? Are most of the interfaces/behaviour the same or will there be a
>> significant number of changes that will need to be made?
>>
>> Felix
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145738 is a reply to message #145729] |
Thu, 19 May 2005 15:15 |
| Eclipse User |
|
|
|
Can't say for sure, but realize that Scanner2.handle* is doing real scanning
work, so you will at least need to call super in your versions. Put a
breakpoint in fetch token at the case '#' and see what happens from there.
-Andrew.
"Felix" <fliao2@yahoo.ca> wrote in message
news:4d7fa617f5bd22a440147f96c45f750e$1@www.eclipse.org...
> Thanks, but I'm having some trouble though. I've made a very simple file:
>
> #if !defined(__MYHEADER_H__)
> #define __MYHEADER_H__
> #endif
>
> Then I made a simple extension of Scanner2, something like:
>
> public class MyScanner extends Scanner2
> {
> public MyScanner(...) {
> super(...);
> System.out.println("MyScanner");
> }
> protected void handlePPDirective(int pos) throws EndOfFileException {
> System.out.println("MyScanner.handlePPDirective");
> }
> }
>
> I then feed my file into my scanner/parser. I see the line "MyScanner" get
> printed out, but I don't see "MyScanner.handlePPDirective". I've also
> tried the same thing on the other handlePP* methods, but to no avail. Any
> idea what I'm doing wrong?
>
> Felix
>
> Andrew Niefer wrote:
>
> > To get all the preprocessor statements using the old parser, you will
need
> > to extend Scanner2 and do something in the process* methods. If you
have an
> > older version of Scanner2, look at the handlePP* methods.
>
> > The interfaces with the new parser are completely different. The old
parser
> > interfaces were syntax and semantic information all in one and the
callbacks
> > happened while we were parsing. The new parser interfaces are seperated
> > into syntactic and semantic components. The new parser doesn't have
> > callbacks, instead you get a fully built syntax tree after the parse is
> > complete. You then visit this tree and ask whatever names you are
> > interested to resolve themselves into a semantic binding.
>
> > A switch would generally involving implementing an ASTVisitor and in
> > visit( IASTName ) inspect the name and the result of
> > IASTName.resolveBinding() to see how whatever logic you used to have in
the
> > callbacks applies.
>
> > -Andrew
>
> > "Felix" <fliao2@yahoo.ca> wrote in message
> > news:118fa16ad0db4734d85554b3eab450d9$1@www.eclipse.org...
> >> I'm working on something that requires all the preprocessor statements,
> >> but I'm using the old parser (which only returns macros and includes in
> >> the callback, as far as I can tell), how would I go about doing that?
As
> >> an aside, what sort of effort would be required to switch over to the
dom
> >> parser? Are most of the interfaces/behaviour the same or will there be
a
> >> significant number of changes that will need to be made?
> >>
> >> Felix
>
|
|
|
| Re: Can't skip AST preprocessor statements? [message #145774 is a reply to message #145738] |
Thu, 19 May 2005 22:28 |
| Eclipse User |
|
|
|
Originally posted by: fliao2.yahoo.ca
Alright, figured it out, it's because the fetchToken, handlePPDirective,
and subsequent handlePP* methods are all private, so I was not overriding
them (I think I copied/pasted my piece of code from a newer version where
they were changed to protected, but I saw the discrepancy when I
downloaded the CDT 2.1.1 source code). Short of overriding all those
functions (which will likely involve a lot of copying and pasting which I
am loathe to do), do I have any other options?
Felix
Andrew Niefer wrote:
> Can't say for sure, but realize that Scanner2.handle* is doing real scanning
> work, so you will at least need to call super in your versions. Put a
> breakpoint in fetch token at the case '#' and see what happens from there.
> -Andrew.
> "Felix" <fliao2@yahoo.ca> wrote in message
> news:4d7fa617f5bd22a440147f96c45f750e$1@www.eclipse.org...
>> Thanks, but I'm having some trouble though. I've made a very simple file:
>>
>> #if !defined(__MYHEADER_H__)
>> #define __MYHEADER_H__
>> #endif
>>
>> Then I made a simple extension of Scanner2, something like:
>>
>> public class MyScanner extends Scanner2
>> {
>> public MyScanner(...) {
>> super(...);
>> System.out.println("MyScanner");
>> }
>> protected void handlePPDirective(int pos) throws EndOfFileException {
>> System.out.println("MyScanner.handlePPDirective");
>> }
>> }
>>
>> I then feed my file into my scanner/parser. I see the line "MyScanner" get
>> printed out, but I don't see "MyScanner.handlePPDirective". I've also
>> tried the same thing on the other handlePP* methods, but to no avail. Any
>> idea what I'm doing wrong?
>>
>> Felix
>>
>> Andrew Niefer wrote:
>>
>> > To get all the preprocessor statements using the old parser, you will
> need
>> > to extend Scanner2 and do something in the process* methods. If you
> have an
>> > older version of Scanner2, look at the handlePP* methods.
>>
>> > The interfaces with the new parser are completely different. The old
> parser
>> > interfaces were syntax and semantic information all in one and the
> callbacks
>> > happened while we were parsing. The new parser interfaces are seperated
>> > into syntactic and semantic components. The new parser doesn't have
>> > callbacks, instead you get a fully built syntax tree after the parse is
>> > complete. You then visit this tree and ask whatever names you are
>> > interested to resolve themselves into a semantic binding.
>>
>> > A switch would generally involving implementing an ASTVisitor and in
>> > visit( IASTName ) inspect the name and the result of
>> > IASTName.resolveBinding() to see how whatever logic you used to have in
> the
>> > callbacks applies.
>>
>> > -Andrew
>>
>> > "Felix" <fliao2@yahoo.ca> wrote in message
>> > news:118fa16ad0db4734d85554b3eab450d9$1@www.eclipse.org...
>> >> I'm working on something that requires all the preprocessor statements,
>> >> but I'm using the old parser (which only returns macros and includes in
>> >> the callback, as far as I can tell), how would I go about doing that?
> As
>> >> an aside, what sort of effort would be required to switch over to the
> dom
>> >> parser? Are most of the interfaces/behaviour the same or will there be
> a
>> >> significant number of changes that will need to be made?
>> >>
>> >> Felix
>>
|
|
|
Goto Forum:
Current Time: Sun May 11 20:57:53 EDT 2025
Powered by FUDForum. Page generated in 0.03442 seconds |
Home