From: Andre B. <and...@gm...> - 2003-04-26 14:00:10
|
Baptiste Lepilleur wrote: >Notes that concerning the function pointer, the most important place to >support them is typedef. In most of the code I have seen, function pointers >were nearly always 'typedefed'. > Function pointers and even the declaration of 'operator' overloading/type-conversion can be detected now. The parser does recognize this and parses it correctly (hopefully!? see Tests), but no information is stored yet. We get Type-Specifiers and Unparsed-Declarators at the moment. Well typedef itselfe is no problem, since it is just one keyword. Note that it can even stay in the middle of a declaration: int typedef mydef; Looks strange ? yes, but the EBNF allows this. Tests took really long (see UnparsedDeclarationMutatorTests), but after all I managed a very clean solution. I first played arround with the VariableDeclMutator which does nearly the same job, but was not able to fullfill all tests and was to complex after adding functionality. I'll try to replace the variable- declaration-mutator as soon as the 'variable-detection' is handled by the new Parser. Durring tests I also recognized a problem in parsing declaration which can not be solved with parser information only (I believe): (Has been added to the Wiki) typedef int myint; class x { public: static myint y; }; myint ::x::y; // <--- how to parse ? (variant a) type "myint::x::y" + no variable (variant b) type "myint::x" + variable "::y" (variant c) type "myint" + variable "::x::y" btw: spaces are allowed between '::' and identifier ("x<space>::y" equals "x::y") "class x ::z::y" has three meanings ! I wrote a test on this (deactivated), but this problem is not high priority. >Concerning code clean-up, you might want to reuse the SourceBuilder class we >use in the rfta library (or implement a similar class, more dedicated to ast >node range). This would makes the tests easier to write, read and maintain. > I was thinking about that, but than decide a different solution. For class body parsing I will check this test solution again. I more and more understand your test routines ;-)... Open tasks for me, at the moment: - class body parsing, supporting additional declaration elements (e.g. public, protected keywords) "UnparsedClassSpecifierMutator" will be created - simple declarator parsing for detecting variables "UnparsedDeclaratorMutator" will be created - function header parsing, to detect parameters "UnparsedFunctionHeaderMutator" will be created - I'm thinking about a new Mutator to replace the MaxLODMutator. This Mutator only accesses Mutator for more details at the specified Source Position. It would allow us for Refactoring Operations to start parsing allways at SourceLevel and than step down to the position where the user has activated some refactoring request. How to name it ? what about "PositionMaxLODMutator" - An additional Mutator could be written which only parses source positions where some identifier does appear. (reuse of the PositionMaxLODMutator) For the future: - to access identifier: identifier resolver strategy for class/namespace/function header --> we need named scopes, and methods to resolve scoped identifier -- André |