Re: [cedet-semantic] c++ smart pointer completion support

[Raf <ra...@fr...>]

Hi Eric,

It's progressing :

variable declaration recognized with template specifier : ok

in semantic-analyze-tag-type I've both the variableTag plus its classTag.
so here I' can :
  - if in classTag there is a "->" function, I can replace classTag with 
the one returned by the "->" function (in case of template I use 
variableTag.template-specifier classTag)

but

* I' don't know if its correct to deal with a specific language issue in 
a non language-specific function.

* I' think it's more correct to set classTag to the class returned bye 
the -> operator (if a c++ class redefine the "->" operator it want to 
act like a pointer of the type returned by the operator) rather than to 
the class owning the -> operator. Ideally it has to be determined by the 
context (is the token followed by a "->" or a "." maybe with overlay 
info, but now I don't know where to find this info. Another compromise 
is to mix the slots of both class : the original + the pointed one, but 
it sound difficult, and also I' don't know how.

Do you think semantic-analyze-tag-type is the correct place to handle this ?
Any risks of bad side effects here ?

For now I've just written dirty code to see if it can work, and it do in 
my limited test cases.

I' will propose you a patch when I' will find the time to write cleaner 
code.

Any hints are welcome.

thanks.

raf.

Eric M. Ludlam a écrit :
> Hi,
>
> I knew operator overloads would eventually show up. :)  I've looked
> into this before, and it is not an incremental change.
>
> The existing parser parses templates just enough to get past them, and
> that works for a large number of templated classes.
>
> The preprocessor cannot do substitutions for anything other than
> symbols.  This is as intended.  A full up lexical redefinition would
> be needed.
>
> As you suggest below, the "right" solution is to remember the template
> specifier for variables.  This seems like the best approach, and
> should be handled in the derived datatype of the variable.  All the
> type dereferencing through the template specifier could then be
> handled nicely as a minor C++ tweak.
>
> In c.by, typeformbase already has a comment waiting to be modified.
> Perhaps like this:
>
> *** c.by.~1.49.~	2008-09-19 23:29:45.000000000 -0400
> --- c.by	2008-11-21 11:49:50.000000000 -0500
> ***************
> *** 664,671 ****
>       (TYPE-TAG $2 $1 nil nil )
>     | builtintype
>       ( ,$1 )
> !  ;;| symbol template-specifier
> !  ;;  ( $1 type "class" )
>    ;;| namespace-symbol opt-stars opt-template-specifier
>    ;;| namespace-symbol opt-template-specifier
>     | namespace-symbol opt-template-specifier
> --- 664,671 ----
>       (TYPE-TAG $2 $1 nil nil )
>     | builtintype
>       ( ,$1 )
> !   | symbol template-specifier
> !     (TYPE-TAG $1 "class" nil nil :template-specifier $2)
>    ;;| namespace-symbol opt-stars opt-template-specifier
>    ;;| namespace-symbol opt-template-specifier
>     | namespace-symbol opt-template-specifier
> ----------------------------
>
> would get you just far enough to get by w/ non-namespace based
> symbols.  Ideally someone would get around to a parser re-write in
> wisent which is sorely needed.
>
> Anyway, once that is available, the name and datatype resolver in the
> analyzer would need to be made aware of template specifiers, and the
> context parser would need to start tracking operator overloading.
>
> I'd be happy to work through some of this if you don't mind working
> through some of the issues w/ me.
>
> Eric
>
>   
>>>> Raf <ra...@fr...> seems to think that:
>>>>         
>> Hello,
>>
>> I'm currently testing the CVS version of semantic. Thanks for this great 
>> and impressive tool.
>>
>> I'm trying to make completion for smart_pointer to work (since most of 
>> my code use it).
>>
>> here is a sample :
>> -----------------------------------
>> template class<T>
>> class ref<T> {
>> public:
>>  T* operator->();
>> };
>>
>>
>> class Foo {
>> public:
>>  int getValue();  
>>  double getResult();
>> };
>>
>>
>> void
>> main(void) {
>>  ref<Foo> d;
>>
>>  d->;
>> }
>> -------------------------------------
>>
>> => I've tried this :
>> (setq semantic-lex-c-preprocessor-symbol-map
>>      '(
>>        ( "ref<Foo>" . ((symbol "Foo" 1 1) (punctuation "*" 1 1)) )
>>       ))
>>
>> but it doesn't work because of the "<" character in the keyword.
>>
>> => I've looking in c.by
>> here the template parameters of the variable declaration seems to be 
>> ignored :
>>
>> namespace-symbol
>>  : symbol opt-template-specifier COLON COLON namespace-symbol
>>    ( (concat $1 "::" (car $5)) )
>>  | symbol opt-template-specifier
>>    ( $1 )
>>  ;
>>
>> It would be nice if we could set a variable that drive substitutions 
>> before the lexer start.
>> Something like "'ref<Foo>' should be read as 'Foo *'"
>> this would add smart_pointer completion support by just a fews lines 
>> (there is usually fews smart pointers types, so identifying them in a 
>> variable is no pain and a lot benefits)
>>
>> ideally the parser should produce tag with the corrects infos, but maybe 
>> it's too complicated for just one use case. (the type tag already have 
>> the infos, but not the variable tag)
>>
>> thanks in advance for any hints, help, suggestions on how to make this work.
>>
>> raf.
>>     
>   [ ... ]
>
>