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

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> 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 ? 

Well, please ignore. If I wasn't answering in the morning I could 
pretend I was too tired.

[...]
>> 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. 

Currently it is an entry point to the symbol table.

> 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 !

I don't get this example, but I think that in general I agree with you.

BR
Grzegorz