CEDET

'sgoericke' writes:
> being a cedet user since a few years i;ve a question about C++11: i have an
> enum with a lot (~3000) members. Because i moved to the new C++ "enum class"
> feature cedet seems to have a big problem with that. Parsing that enum takes a
> lot of time (about 50min) and with the result that no symbols are found.
>  
> I guess cedet/semantic doesn't support those constructs yet. However, instead
> of changing my source i would like to help that semantic can parse "enum class"
> correctly. However i need a hint where to start in the parser. Maybe somebody
> can tell me which file or function is responsible to parse enums in C++?

First you'd have to change the grammar to recognize the constructs you
want. The current enum parsing is this rule in typesimple:

  | ENUM opt-class opt-name enumparts
    (TYPE-TAG (car $3) $1 $4 nil
              :parent (car ,$2))

And the members of the enums are parsed in those two rules:

enumparts
  : semantic-list
    (EXPANDFULL $1 enumsubparts)
  ;

enumsubparts
  : symbol opt-assign
    (VARIABLE-TAG $1 "int" (car $2) :constant-flag t )
  | LBRACE
    ( nil )
  | RBRACE
    ( nil )
  | COMA
    ( nil )
  ;

It's hard to tell how hard it would be to add parsing for C++11 enum
classes. It doesn't look too bad, but with C++ you can never be sure.

-David

Ok,

i wouldn't say it was simple but got it working :-)

I wouldn't say it's bug-free and of course i don't know what 
side-effects this change produces. However it works (and also "normal" 
enums are still parsed properly).

I've attached a patch for "c.by". Also attached is an archive with 
simple test-source and a screenshot ;-)

Regards
Sven

On 10/29/2012 08:10 PM, David Engster wrote:
> 'sgoericke' writes:
>> being a cedet user since a few years i;ve a question about C++11: i have an
>> enum with a lot (~3000) members. Because i moved to the new C++ "enum class"
>> feature cedet seems to have a big problem with that. Parsing that enum takes a
>> lot of time (about 50min) and with the result that no symbols are found.
>>
>> I guess cedet/semantic doesn't support those constructs yet. However, instead
>> of changing my source i would like to help that semantic can parse "enum class"
>> correctly. However i need a hint where to start in the parser. Maybe somebody
>> can tell me which file or function is responsible to parse enums in C++?
>
> First you'd have to change the grammar to recognize the constructs you
> want. The current enum parsing is this rule in typesimple:
>
>    | ENUM opt-class opt-name enumparts
>      (TYPE-TAG (car $3) $1 $4 nil
>                :parent (car ,$2))
>
> And the members of the enums are parsed in those two rules:
>
> enumparts
>    : semantic-list
>      (EXPANDFULL $1 enumsubparts)
>    ;
>
> enumsubparts
>    : symbol opt-assign
>      (VARIABLE-TAG $1 "int" (car $2) :constant-flag t )
>    | LBRACE
>      ( nil )
>    | RBRACE
>      ( nil )
>    | COMA
>      ( nil )
>    ;
>
> It's hard to tell how hard it would be to add parsing for C++11 enum
> classes. It doesn't look too bad, but with C++ you can never be sure.
>
> -David

Sven Goericke writes:
> I've attached a patch for "c.by". Also attached is an archive with
> simple test-source and a screenshot ;-)

Thanks! You can always try the CEDET unit and integration tests to see
if your changes broke something. You can run them by doing 'make utest',
'make itest-make' and 'make itest-automake', although the latter two are
more targeted at EDE. When changing C/C++ parsing, another good test is
to run an integration test I added just recently; it parses some STL
classes and hence requires an installed STL. I can be started by doing
'make itest-stl-batch'.

Do you have papers signed with the FSF? Your change would qualify as a
'tiny change' and thus wouldn't need them, but if you plan on submitting
further changes to CEDET and/or Emacs in the future, it can't hurt to do
that now, since this process can take a couple of weeks.

-David

Glad to hear the patch might be useful. Haven't signed any papers with 
the FSF yet. About "plans" to submit changes and/or contribute to 
CEDET/Emacs: at least i will try to fix problems by myself (if i find 
any) or add features i need. Of course i would publish patches.

I'm aware about unit-tests but never used them in lisp (i'm not an 
"guru" in lisp). However i use them heavy in C++. I just started on an 
emacs-mode for the Boost.Test framework. At the moment it's really basic 
but i've plans for it. It's available on github: 
https://github.com/sgoericke/boost-test

If you think that support for Boost.Test (or Qt-Test or google-test) 
would be a nice feature for CEDET and have an idea where to "start" 
within the CEDET stuff to support such test-frameworks let me know :-)

Regards
Sven

On 10/30/2012 11:09 PM, David Engster wrote:
> Sven Goericke writes:
>> I've attached a patch for "c.by". Also attached is an archive with
>> simple test-source and a screenshot ;-)
>
> Thanks! You can always try the CEDET unit and integration tests to see
> if your changes broke something. You can run them by doing 'make utest',
> 'make itest-make' and 'make itest-automake', although the latter two are
> more targeted at EDE. When changing C/C++ parsing, another good test is
> to run an integration test I added just recently; it parses some STL
> classes and hence requires an installed STL. I can be started by doing
> 'make itest-stl-batch'.
>
> Do you have papers signed with the FSF? Your change would qualify as a
> 'tiny change' and thus wouldn't need them, but if you plan on submitting
> further changes to CEDET and/or Emacs in the future, it can't hurt to do
> that now, since this process can take a couple of weeks.
>
> -David