Re: [Cpptool-develop] Declaration parsing started...

[Andre B. <and...@gm...>]

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é