Re: [Opencxx-users] parse error on valid code

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:
> Hi all,
> 
> Shigeru Chiba wrote:
> 
> [...]
> 
>>Yes, parsing C++ code should not need backward references with respect to
>>types.
> 
> 
> AFAIK with this exception:
> 
> struct A
> {
>     void f(B);
>     typedef B int;
> };

huh ? Make that

struct A
{
   typedef int B;
   void f(B);
};

and everything is fine (and covered by what was already said).


> I think we can keep the OpenC++ parser clean with this design:
> 
>                  <<iface>>
> +--------+     +--------------+
> | Parser |---->| TypeResolver |
> +--------+     +--------------+
> 
> Where TypeResolver instance provides all the functionality requiring
> maintaining the type name table. Perhaps ClassWalker or Environment can
> be made an implementation of TypeResolver. That way code would stay not
> tangled (i.e. Parser still does not implement type name table, nor does
> it depend on concrete classes from the next layers, like Environment or
> ClassWalker).

yes, agreed. The Parser is complex enough as it is right now. What is
needed (and what the Parser will have to interact with) is a symbol
resolver that can report whether a symbol is known, and what its (meta) type
is, i.e. one of 'type', 'variable', 'compile-time const'.
This symbol resolver needs to know the rules for symbol lookup with multiple
scopes. That's quite hairy in itself.

However, I don't see how ClassWalker relates to that. Well, if ClassWalker
currently serves to report back known symbols, that's one thing. However,
symbol lookup mustn't be done in a second AST traversal parse, but (as
we now seem to agree) as soon as information about new symbols gets
available. Parser and Symbol resolver really need to work hand in hand.
Just think about declarations such as

template <size_t FOOBAR> struct Baz {};

where the parser needs to know that FOOBAR is a compile-time constant.
It's not even a type !

Regards,
		Stefan