Hello,
You are right, the identification of -> and subsequent change of
data type should belong in a C specific function.
If you look in cedet/semantic/bovine/semantic-c.el you will see an
overload for semantic-analyze-dereference-metatype. This is used by
semantic-analyze-tag-type. A short hack might be to augment this to
identify a class with a -> operator, and do a transformation.
Alternately, it occurs to me, this could be augmented with a
user-supplied list of transformations to handle smart pointers.
To know if we want to translate smart pointers as a metatype, we
need to identify when we use -> vs . and capture that information in
the local context parser. It may be necessary to write a whole new
routine that can parse more complex statements. Semantic already
misses a wide range of cast syntax. This should probably be a custom
C parser.
Anyway, I'd recommend the metatype hack to get started. It may be
that is good enough for you in the short term. Longer term projects
of identifying -> and such will take longer, and will be able to take
advantage of what you learn.
Eric
>>> Raf <raf.ml@...> seems to think that:
>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 <raf.ml@...> 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.
>>>
>> [ ... ]
>>
>>
>
>
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net
|