Menu
▾
▴
cpptool-develop
|
From: Andre B. <and...@gm...> - 2002-12-20 20:45:07
|
Well, since holidays start I'm not sure if my family is taking to much of my spare time :-) But I will check the Dev-C++ IDE and think about parsing full files, which need to be discussed isn't it ? And testing of cause the VC6 plug in ! Tell me Baptiste if there's a small job like the last one. -- Andre |
|
From: Baptiste L. <gai...@fr...> - 2002-12-20 22:01:58
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, December 20, 2002 9:20 PM Subject: [Cpptool-develop] Next things .. > Well, since holidays start I'm not sure if my family is taking to much > of my spare time :-) > But I will check the Dev-C++ IDE and think about parsing full files, > which need to be discussed isn't it ? Yes. I already have some ideas concerning this. The difficult part will probably be dealing with unknown macros which do not end with a semi-colon. It will be fairly import that the full parser has good fault tolerance. > And testing of cause the VC6 plug in ! > Tell me Baptiste if there's a small job like the last one. Well, I can't think of one now, but you could get started on the IntroduceExplainingVariable refactoring. While it is not possible at the current time, when the full parser will be done, we might want to try to guess the return type of the extracted expression instead of asking it to the user. I don't know for you, but I often use this refactoring when dealing with a long chain of call: contact.getAddress().getPostalCode() => const Address &address = contact.getAddress(); address.getPostalCode(); If the type of 'contact' is known (and the class declaration), we should be able to guess the type of the expression. This will be difficult as it will require expression analysis and interpretation. Baptiste. > -- Andre |
|
From: Andre B. <and...@gm...> - 2002-12-21 07:53:22
|
Baptiste Lepilleur wrote:
>>Well, since holidays start I'm not sure if my family is taking to much
>>of my spare time :-)
>>But I will check the Dev-C++ IDE and think about parsing full files,
>>which need to be discussed isn't it ?
>>
>>
>
>Yes. I already have some ideas concerning this. The difficult part will
>probably be dealing with unknown macros which do not end with a semi-colon.
>It will be fairly import that the full parser has good fault tolerance.
>
what about adding first:
- support of parsing functions/methods with there header
- support of parsing class declarations
- parse full files including macro definitions and think about fault
tolerance
Some strategy on beeing fault tollerant could be to introduce AST-Nodes
for not parsable code-parts
and also for not known type information for symbols.
>
>
>
>>And testing of cause the VC6 plug in !
>>
>>
>
>
>
>>Tell me Baptiste if there's a small job like the last one.
>>
>>
>
>Well, I can't think of one now, but you could get started on the
>IntroduceExplainingVariable refactoring.
>
>While it is not possible at the current time, when the full parser will be
>done, we might want to try to guess the return type of the extracted
>expression instead of asking it to the user.
>
>I don't know for you, but I often use this refactoring when dealing with a
>long chain of call:
>
>contact.getAddress().getPostalCode()
>=>
>const Address &address = contact.getAddress();
>address.getPostalCode();
>
>If the type of 'contact' is known (and the class declaration), we should be
>able to guess the type of the expression. This will be difficult as it will
>require expression analysis and interpretation.
>
Yeah I would try, but we need to parse class declarations to collect
this information isn't it ?
Since we need to known about a classes members/methods.
This needs the introduction of new AST-NodeTypes, any suggestions ?
I'm allready starting to think about this -- so if it's ok for you than
I will open a new to-do-item
on the Wiki pages... lets say,
"Parse method implementation and class declaration"
Some test example which should work after this extension:
class Name {
method_declaration ( ... parameters ...) ; /* optional implementation */
}
method_declaration ( ... parameters ... )
{ /* compound statement parsed using the current parser implementation */
}
-- Andre
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-21 10:35:08
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppTool Mailing List" <Cpp...@li...> Sent: Saturday, December 21, 2002 8:46 AM Subject: Re: [Cpptool-develop] Next things .. > Baptiste Lepilleur wrote: > [...] > >>But I will check the Dev-C++ IDE and think about parsing full files, > >>which need to be discussed isn't it ? > >> > >> > > > >Yes. I already have some ideas concerning this. The difficult part will > >probably be dealing with unknown macros which do not end with a semi-colon. > >It will be fairly import that the full parser has good fault tolerance. > > > what about adding first: > - support of parsing functions/methods with there header > - support of parsing class declarations > - parse full files including macro definitions and think about fault > tolerance > Some strategy on beeing fault tollerant could be to introduce AST-Nodes > for not parsable code-parts > and also for not known type information for symbols. > -- Andre The parser does not know anything about types. It only see identifiers: it is a context less parser. This makes the parser a lot more tolerant, which is a reason why we can get away without a preprocessing step. The parser only care about identifier, and don't know weither a type is 'known' or not. More complex information about type will be provided by the code analysis layer which analyse the AST, much like was done for locale variables with IdentifierResolver. Because of the nature of the parser we are writing (level of detail aspect), it is easier to go by increasing the level of detail. The first step would be being able to parse (even at a gross level of detail) a full file. At the top of my head, this includes the following structure: - namespace keyword - using keyword - template keyword - export keyword (don't know much about that one, but there is a small article on CUJ: http://cuj.com/webonly/2003/0302/web0302b/web0302b.htm) - class and struct keyword - enum keyword - extern keyword - function declaration/implementation - global variable declaration - macro usage The initial implementation of those parser can be fairly simplistic (much like the current class and struct parser). We should probably begin by implementing fault tolerance for the existing Statementsparser to see how this can be done.. I've added a page on the Wiki: http://cpptool.sourceforge.net/cgi-bin/wiki.pl?FullParser Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-21 10:55:27
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>; "CppTool Mailing List"
<Cpp...@li...>
Sent: Saturday, December 21, 2002 8:46 AM
Subject: Re: [Cpptool-develop] Next things ..
> Baptiste Lepilleur wrote:
>
[...]
> >Well, I can't think of one now, but you could get started on the
> >IntroduceExplainingVariable refactoring.
> >
> >While it is not possible at the current time, when the full parser will
be
> >done, we might want to try to guess the return type of the extracted
> >expression instead of asking it to the user.
> >
> >I don't know for you, but I often use this refactoring when dealing with
a
> >long chain of call:
> >
> >contact.getAddress().getPostalCode()
> >=>
> >const Address &address = contact.getAddress();
> >address.getPostalCode();
> >
> >If the type of 'contact' is known (and the class declaration), we should
be
> >able to guess the type of the expression. This will be difficult as it
will
> >require expression analysis and interpretation.
> >
> Yeah I would try, but we need to parse class declarations to collect
> this information isn't it ?
Like I said above, this is not possible at the current time. A full parser
is needed. The current implementation of IntroduceExplainingVariable would
simply do the following things:
- ask the user for the type and name of the extracted expression
- add a variable declaration before the statement in which the expression
appears (may need to add a compound statement)
- replace the extracted expression with a reference to the new locale
variable.
> Since we need to known about a classes members/methods.
> This needs the introduction of new AST-NodeTypes, any suggestions ?
Yes, this will be needed, but let's focus on the method level analysis for
now. There is still much to do and clean up in the current implementation:
ASTNode polymorphism issues, node type features, code rewriter....
Even when we will have a full parser, I don't think that such expression
analysis will not be so high in the priority least as it is only a
convenience. It is fairly difficult to implement and is only a convenience.
There will be much more interresting and useful refactorings to implement
then.
> I'm allready starting to think about this -- so if it's ok for you than
> I will open a new to-do-item
> on the Wiki pages... lets say,
> "Parse method implementation and class declaration"
Parsing for method or function declarations should probably be done while
dealing with variable and attribute declaration. I expect some ambiguity to
appears, much like what happened with the expression and locale variable
declaration.
> Some test example which should work after this extension:
>
> class Name {
> method_declaration ( ... parameters ...) ; /* optional implementation
*/
> }
>
> method_declaration ( ... parameters ... )
> { /* compound statement parsed using the current parser implementation */
> }
>
> -- Andre
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-22 13:29:32
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Sunday, December 22, 2002 1:42 PM Subject: Re: [Cpptool-develop] Next things .. > >The current implementation of IntroduceExplainingVariable would > >simply do the following things: > >- ask the user for the type and name of the extracted expression > >- add a variable declaration before the statement in which the expression > >appears (may need to add a compound statement) > >- replace the extracted expression with a reference to the new locale > >variable. > > > So I will try to figure out more about the refactoring code ... getting > into this. You may want to try for the InlineTemp refactoring instead of IntroduceExplainingVariable. It's fairly close to RenameTemp and is mainly a search and replace. Deciding where the declaration should be added for IntroduceExplainingVariable is not a simple matter. The code model I'm creating will hopefully help with that. [...] > I was starting to think about a "code rewriter" solution but well, it > seams to me quite complex and > stoped thinking about this for the moment. I could write down some of my > ideas (which will be > incomplete since I need to get more into the code of the whole thing). I was blocked on this topic for a long time, but I had an idea yesterday (still ill defined) which I'm trying to implement. Basically, when you will do: CompoundStatementPtr compound= ...; compound->appendStatement( new WhileStatement( ... ) CompoundStatement will memorize that a new statement was added and rewrite the code as required. [...] > >Parsing for method or function declarations should probably be done while > >dealing with variable and attribute declaration. > > > okido, I'm with you. I skimmed a bit of the C++ standard concerning declaration (by the way, the outtermost level of a source file is only about declaration), and I can say that it's not going to be simple. Beyond parsing, one important thing that we will need to achieve is defining a code model for type representation, so that we will know if a local variable is an instance of a given class, a pointer... Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 20:21:55
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...> Sent: Sunday, December 22, 2002 3:35 PM Subject: Re: [Cpptool-develop] Next things .. > Baptiste Lepilleur wrote: > [...] > >I was blocked on this topic for a long time, but I had an idea yesterday > >(still ill defined) which I'm trying to implement. Basically, when you will > >do: > > > >CompoundStatementPtr compound= ...; > >compound->appendStatement( new WhileStatement( ... ) > > > >CompoundStatement will memorize that a new statement was added and rewrite > >the code as required. > > > So you think about implementing the code writer within extra classes for > the statement types ? > I was thinking about using some visitation of the parsed AST and to do > the rewriting on basis of the > parsed AST. This kind of rewriter would use the original source code > parts that cannot be parsed yet > (maybe remove new lines or extra whitespaces) and introduces the > formatting for all known code parts. > Also the idea of configurable formatting has to be included. I was > thinking about having some formatter > context that knows about the settings how to format and for instance > the level for indention etc. > The visitor can than collect the formatted code. You need more than just the new AST to rewrite the code. You also need to know which node were deleted, and which were replaced to know which part of the original source need to be modified. The CodeModel provided a somewhat higher level of abstraction of the code. For instance, in the AST, the type of an declaration node is the same weither it is a statement or an expression. The CodeModel clearly distinguish both case. If things work out correctly, the current refactoring will be modified to use the code model instead of doing direct text manipulation. The new classes living in CodeModel will not rewrite the code directly. They will remember the change made and their original SourceRange is they where generated from parsing. When the rewriting occurs, those change are collected during visitation and the rewriting will be done based on those change. This rewritting will also need to be combined with a formatter. Making formatting configurable will be trivial once we manage to do it. My current confusion is more around of what we should reformat and when: - For an ExpressionStatement, should it be completly reformatted if a part of the expression changed ? (a variable was renamed for instance) - For conditional statements, should the condition be reformatted if the condition expression changed ? At the current, I'm going for 'no' as an answer to both questions since we don't know how to reformat expression at the current time. Reformatting will only occur for modification of a CompoundStatement (call to add/remove/set). Also, notes that it is better to just replace what need to be as it is easier on the undo buffer of the IDE (this is just the matter of doing a 'skip over' instead of copying). Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2002-12-23 20:31:00
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>
Sent: Sunday, December 22, 2002 3:35 PM
Subject: Re: [Cpptool-develop] Next things ..
> Baptiste Lepilleur wrote:
> [...]
> >I skimmed a bit of the C++ standard concerning declaration (by the way,
the
> >outtermost level of a source file is only about declaration), and I can
say
> >that it's not going to be simple.
> >
> Yep, but I was looking through the ebnf-syntax today. The result of this
> is this addition to your FullParser
> wiki page. After having some "lazy parsing" declaration parser for the
> source level, we could add the
> features step by step. For that reason I started to think about how to
> find out the different types of declaration
> which are in fact not too many and than findout their end symbol ";" or
"}".
> At highest level that are only 6 different kinds of declaration
> - block decl (this is the interessting stuff, classes/struct/typedef,
etc.)
> - function decl
> - different template declarations
> - extern declaration (extern "identifier" { ... } )
> - namespace declaration
>
> the identification and getting the length of extern, namespace is not to
> difficult.
> the identification of template-declaration is easy but getting the
> length is worse because the declaration can recurse
> the length of block-declaration is easy since all of the sub types end
> with ";" and I think none of them has a ";" inside (need to check this)
> identification between block and function declaration is described in
> the wiki and follows the idea, that only a function implementation
> has a brace ")" just before the compound statement whereas for block
> declaration that use "{}" no such thing can happen.
I went over the wiki and the basic ideas is there. If you look at the
StatementsParser you see it's a lot like the declarations parsing. Though
finding the end of declarations is a bit trickier. Take the following case
for instance:
static int values[] = { 1,2, 3 };
The declaration does not stop at the brace, but at the semicolon. But
detecting the brace and semi-colon and backtracking is the way to go for
complex declarations, but should not be necessary for basic constructs
(using, namespace...)
Thinking about it, fault tolerance could probably be introduced when nothing
else is matched for a declaration (that's how I would do it for the
StatementsParser). Then, it would skip text (while balance curly brace)
until a semi-colon is found.
Baptiste.
|
×
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