Menu
▾
▴
cpptool-develop
|
From: Baptiste L. <gai...@fr...> - 2003-05-01 10:10:44
|
I've added a python script in the bin/ directory. It scan the
subdirectories of bin/testdata/ and run the parser in all the file found
there. The directory structure is duplicated in ast/ and the HTML ast dump
are copied here. An index page is created in ast/index.html with link to all
ast, as well as parsing status (ok, failed, and crashed).
The script must be run from the bin/ directory, and expect to find a
binary named 'astdump' there.
For the curious, you can find the zipped resultat:
http://gaiacrtn.free.fr/temp
the ast directory you'll find there only contains a subset of the zip
file (ogre & rfta).
The source were picked up from some C++ project on sourceforge.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 17:33:20
|
Well, I run astdump on a large amount of files. Here are the result
(number are files):
Passed 3008 : 82%
Failed 614 : 16%
Crashed 9 : 0%
Total tests: 3631
I would say that it's pretty good considering how young the parser is.
Some of the bugs I saw comming often:
- constructor parsing
- operator = support (or something like that)
- friend function declaration
- inline support
- using symbol;
- __asm
Also, as indicated above, there was 9 crashes and the parser also went
in an infinite loop while parsing some files (getopt.c for instance).
I've updated bug/list.txt with those I found after looking at some of
the failure (there is just too much to look at them all).
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 18:23:17
|
I investigated a bit, and the crashed were not really crash (just bad
command line passed to astdump. filename contained spaces).
The infinite loop are caused by K&R function style declaration, such as:
int
main (argc, argv)
int argc;
char **argv;
{
}
As weird as it sound, it is used in 'common' files, such as getopt.c,
getopt1.c or unzip.c.
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Sunday, May 25, 2003 7:37 PM
Subject: [Cpptool-develop] astdump runner...
> Well, I run astdump on a large amount of files. Here are the result
> (number are files):
> Passed 3008 : 82%
>
> Failed 614 : 16%
>
> Crashed 9 : 0%
>
> Total tests: 3631
>
> I would say that it's pretty good considering how young the parser is.
>
> Some of the bugs I saw comming often:
>
> - constructor parsing
>
> - operator = support (or something like that)
>
> - friend function declaration
>
> - inline support
>
> - using symbol;
>
> - __asm
>
> Also, as indicated above, there was 9 crashes and the parser also went
> in an infinite loop while parsing some files (getopt.c for instance).
>
> I've updated bug/list.txt with those I found after looking at some of
> the failure (there is just too much to look at them all).
>
> Baptiste.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-01 21:58:37
|
Fixed 4 bugs and removed all crashes: - readUntilNextOf() caused silent failures as it iterated to the end without throwing exception. It now throw an exception uppon failure. tryReadNextOf() as been added to handle case were you need to continue - class forward declaration support - destructor declaration support (not clean, will need to be made more robust) - multiple access declaration support 'public: protected:' 51% of the 49 files are now being parsed ! Things are looking up. Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, May 01, 2003 12:14 PM Subject: [Cpptool-develop] astdump runner... > I've added a python script in the bin/ directory. It scan the > subdirectories of bin/testdata/ and run the parser in all the file found > there. The directory structure is duplicated in ast/ and the HTML ast dump > are copied here. An index page is created in ast/index.html with link to all > ast, as well as parsing status (ok, failed, and crashed). > > The script must be run from the bin/ directory, and expect to find a > binary named 'astdump' there. > > For the curious, you can find the zipped resultat: > http://gaiacrtn.free.fr/temp > the ast directory you'll find there only contains a subset of the zip > file (ogre & rfta). > > The source were picked up from some C++ project on sourceforge. > > Baptiste. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > |
|
From: Baptiste L. <gai...@fr...> - 2003-05-05 08:21:04
|
Fixed a few more bugs: - nested case constant (case X::value :) - enum parsing (parsed as a declaration list failed (no ';') ) - support for class EXPORT_MACRO ClassName - general macro acceptance in declaration list based on case style (matched if ID_ID(...)). Allow wxWindow & MFC macros to be parsed succesfully 74% of the files are now being parsed. I've checked ast/ogre/ogrebspscenemanager.cpp.html at statement level and the parsing is nearly perfect (spotted two minors bugs). For the curious, you can find the zipped resultat (I've fixed the url link bug): http://gaiacrtn.free.fr/temp the ast directory you'll find there only contains a subset of the zip file (audacity, ogre & rfta). On major bug remaining concerns the parsing of constructor declaration in class declaration. Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, May 02, 2003 12:02 AM Subject: Re: [Cpptool-develop] astdump runner... > Fixed 4 bugs and removed all crashes: > - readUntilNextOf() caused silent failures as it iterated to the end without > throwing exception. It now throw an exception uppon failure. tryReadNextOf() > as been added to handle case were you need to continue > - class forward declaration support > - destructor declaration support (not clean, will need to be made more > robust) > - multiple access declaration support 'public: protected:' > > 51% of the 49 files are now being parsed ! Things are looking up. > > Baptiste. > > ----- Original Message ----- > From: "Baptiste Lepilleur" <gai...@fr...> > To: "CppTool Mailing List" <Cpp...@li...> > Sent: Thursday, May 01, 2003 12:14 PM > Subject: [Cpptool-develop] astdump runner... > > > > I've added a python script in the bin/ directory. It scan the > > subdirectories of bin/testdata/ and run the parser in all the file found > > there. The directory structure is duplicated in ast/ and the HTML ast dump > > are copied here. An index page is created in ast/index.html with link to > all > > ast, as well as parsing status (ok, failed, and crashed). > > > > The script must be run from the bin/ directory, and expect to find a > > binary named 'astdump' there. > > > > For the curious, you can find the zipped resultat: > > http://gaiacrtn.free.fr/temp > > the ast directory you'll find there only contains a subset of the zip > > file (ogre & rfta). > > > > The source were picked up from some C++ project on sourceforge. > > > > Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2003-05-14 20:31:24
|
Welcome back Andre. I saw that you fixed a few parsing bugs. It's now up to
81% being parsed. The major remaining bug concerns parsing constructor
declaration inside class (see file bug/list.txt for details).
I've also experimented with implementing a mini-parser (see MiniParserTest).
It's work well, but I have not yet figured out a good way to collect matched
range. My idea is not to use those mini-parser for the full implementation,
but for small piece of the parser, such as
'class' export-macro class-name ':' inheritance {
Nearly everything to parse the above structure is optional and the code get
difficult to read. I believe such a thing would allow for serious code clean
up, if we found a good way to retrieve the matched range.
One idea I had was something like that:
CStringView classDecl, className;
// parser for: 'class' class-name :
const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
>>
Xtl::CppIdentifierMiniParser()[className]
>> Xtl::CharMiniParser(
':' ))[classDecl];
But this would not work when working with repetition parser (for example, to
matchthe repetition of ('::' id) ). Any ideas ?
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, May 05, 2003 10:25 AM
Subject: Re: [Cpptool-develop] astdump runner...
> Fixed a few more bugs:
> - nested case constant (case X::value :)
> - enum parsing (parsed as a declaration list failed (no ';') )
> - support for class EXPORT_MACRO ClassName
> - general macro acceptance in declaration list based on case style
(matched
> if ID_ID(...)). Allow wxWindow & MFC macros to be parsed succesfully
>
> 74% of the files are now being parsed. I've checked
> ast/ogre/ogrebspscenemanager.cpp.html at statement level and the parsing
is
> nearly perfect (spotted two minors bugs).
>
> For the curious, you can find the zipped resultat (I've fixed the url link
> bug):
> http://gaiacrtn.free.fr/temp
> the ast directory you'll find there only contains a subset of the zip file
> (audacity, ogre & rfta).
>
> On major bug remaining concerns the parsing of constructor declaration in
> class declaration.
>
> Baptiste.
|
|
From: Andre B. <and...@gm...> - 2003-05-15 16:15:31
|
Baptiste Lepilleur wrote:
>Welcome back Andre. I saw that you fixed a few parsing bugs. It's now up to
>81% being parsed. The major remaining bug concerns parsing constructor
>declaration inside class (see file bug/list.txt for details).
>
ok, I missed that point - i check these as soon as possible.
>I've also experimented with implementing a mini-parser (see MiniParserTest).
>It's work well, but I have not yet figured out a good way to collect matched
>range. My idea is not to use those mini-parser for the full implementation,
>but for small piece of the parser, such as
>
>'class' export-macro class-name ':' inheritance {
>
>Nearly everything to parse the above structure is optional and the code get
>difficult to read. I believe such a thing would allow for serious code clean
>up, if we found a good way to retrieve the matched range.
>
>One idea I had was something like that:
>
>CStringView classDecl, className;
>// parser for: 'class' class-name :
>const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
> >>
>Xtl::CppIdentifierMiniParser()[className]
> >> Xtl::CharMiniParser(
>':' ))[classDecl];
>
>But this would not work when working with repetition parser (for example, to
>matchthe repetition of ('::' id) ). Any ideas ?
>
Well - it should work if the repeatition parser does some look ahead and
allows only "::" to be 'eaten'
(than it will stop at a single colon).
Apart from that:
is it possible to declare a class like this
class XXX::class_name : public C {
};
The miniparser stuff sounds good - seems to go into the direction of the
boost parser but a little
bit more lightweight. I like this idea, since much code of the
declaration parser is not very easy to
understand and I do feel that this could make some things easier.
During the last days I started to work a little bit on the
IdentifierResolver for supporting
Class/Namescopes. That will take a while -depending on the time I can
spent for this
project, I will see if bug fixing and code clean up will be done first /
in parallel or what ever :-).
I have finished a class "IdentifierScope" which can hold information on
sub scopes, as well as
parent and root scope. It is possible to register identifier with their
ASTNodePtr. Some more
tests need to be written. Next step will be the integration in
"IdentifierScopeResolverContext".
I plan to move some of the implementation into IdentifierScope.
What do you think about this ?
Next week I'm definitly away and I don't know yet how much time is taken
by my job
after this...
until then,
André
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 19:30:31
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, May 15, 2003 6:22 PM
Subject: Re: [Cpptool-develop] astdump runner...
> Baptiste Lepilleur wrote:
> >One idea I had was something like that:
> >
> >CStringView classDecl, className;
> >// parser for: 'class' class-name :
> >const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
> > >>
> >Xtl::CppIdentifierMiniParser()[className]
> > >> Xtl::CharMiniParser(
> >':' ))[classDecl];
> >
> >But this would not work when working with repetition parser (for example,
to
> >match the repetition of ('::' id) ). Any ideas ?
> >
> Well - it should work if the repeatition parser does some look ahead and
> allows only "::" to be 'eaten'
I not clear in my question. I was not refering to 'how to get the (::id)*
pattern to work' (the mini-parser has infinite look-ahead, but how to store
the matched results. When this pattern is matched, you will want the range
of each matched 'token' (:: or id), and the range of the matched pattern.
That same pattern can be part of a much larger one (the begining of a class
declaration). The resulting matched range can be seen as a list, but the
user will need the tree structure to use them. For example, if you match
something like 'class' +(::Id) ?( '{' ... '}') ';', the resulting would look
like something like this:
+ ['class' range]
+ [+(::Id) range]
|-+['::']
|-+[Id]
|-+['::']
|-+[Id]
+ ['{' ... '}'] // may not be present
+ [';']
The user need to be able to request a given matched range easily, but I not
found a simple way to do that yet. The tree structure and optional element
make this difficult, and I'm not even getting into the presence of
alternative...
> (than it will stop at a single colon).
> Apart from that:
> is it possible to declare a class like this
> class XXX::class_name : public C {
> };
Yes, and it's fairly common (pimpl idiom):
class Main
{
class Impl;
};
class Main::Impl : public BaseImpl
{
};
> The miniparser stuff sounds good - seems to go into the direction of the
> boost parser but a little
> bit more lightweight. I like this idea, since much code of the
> declaration parser is not very easy to
> understand and I do feel that this could make some things easier.
Its strongly inspired from Boost.Spirit, but I took all the thing we don't
need out, prefering simplicity over flexibility (we can have only one
scanner, but it's enough for us). I started experimental with after fixing a
few parsing issues with class declaration. There so much things that could
be optional and different but similar alternative that the code was getting
fairly complicated. The parser would solve this if we could get the matched
ranges out, as well as the matched alternative.
Baptiste.
|
|
From: Andre B. <and...@gm...> - 2003-05-16 05:50:43
|
Baptiste Lepilleur wrote:
>Yes, and it's fairly common (pimpl idiom):
>class Main
>{
> class Impl;
>};
>
>class Main::Impl : public BaseImpl
>{
>};
>
>
Oh yes I forgot about that....
>>The miniparser stuff sounds good - seems to go into the direction of the
>>boost parser but a little
>>bit more lightweight. I like this idea, since much code of the
>>declaration parser is not very easy to
>>understand and I do feel that this could make some things easier.
>>
>>
>
>Its strongly inspired from Boost.Spirit, but I took all the thing we don't
>need out, prefering simplicity over flexibility (we can have only one
>scanner, but it's enough for us). I started experimental with after fixing a
>few parsing issues with class declaration. There so much things that could
>be optional and different but similar alternative that the code was getting
>fairly complicated. The parser would solve this if we could get the matched
>ranges out, as well as the matched alternative.
>
yep I strongly agree with this - the declaration parser did get very
complex and in some parts not
very readable.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X