Thread: [CEDET-devel] libc++ parsing issues
Brought to you by:
zappo
From: Alastair R. <ala...@gi...> - 2014-04-25 22:34:22
Attachments:
signature.asc
|
Hi, I have been trying to use Semantic with the libc++ implementation of the C++ standard library. I think there are some parsing issues. (The code in question can be browsed or downloaded from here: http://libcxx.llvm.org) The std namespace is declared using (yet more) macros, this time _LIBCPP_{BEGIN,END}_NAMESPACE_STD. I believe these aren't parsed correctly, so the declarations end up in the global namespace. Note that the definition itself uses the "inline namespace" feature of C++11: #define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace _LIBCPP_NAMESPACE { #define _LIBCPP_END_NAMESPACE_STD } } libc++ uses visibility macros such as _LIBCPP_INLINE_VISIBILITY and _LIBCPP_TYPE_VIS_ONLY. These resolve to attibute declarations such as: #define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default"))) This, or perhaps something else, prevents the vector template declaration being parsed. The declaration itself is this: template <class _Tp, class _Allocator = allocator<_Tp> > class _LIBCPP_TYPE_VIS_ONLY vector : private __vector_base<_Tp, _Allocator> { // contents elided }; Which is parsed as: ("__vector_base" variable (:type "int") nil #<overlay from 17184 to 31629 in vector>) I think there are also other parsing issues relating to the use of _NOEXCEPT_ macros - but my main problem right now is to get the vector declaration parsed correctly. Please let me know if more information is needed. |
From: Eric M. L. <er...@si...> - 2014-04-30 02:30:59
|
Hi Alistair, The preprocessor in CEDET can't handle macros with open { in them using the typical declarative mechanism. Because this pattern is common, however, there are some custom lexical perasers in semantic/bovine/c.el. You can find them if you search for "BEGIN_NAMESPACE", but the ones in there are for GLIBCXX. You can probably copy the lexer for the VC++ version to add this new one and try it out. The TYPE_VIS should work if you add the correct header to semantic-lex-c-preprocessor-symbol-file. If you are using gcc, you will need to require semantic/bovine/c before setting up that variable. After adding something to it, be sure to call semantic-c-reset-preprocessor-symbol-map. If these tricks work out, we can add a patch to semantic/bovine/c to make this easier for the next person. Thanks Eric On 04/25/2014 06:21 PM, Alastair Rankine wrote: > Hi, > > I have been trying to use Semantic with the libc++ implementation of the > C++ standard library. I think there are some parsing issues. > > (The code in question can be browsed or downloaded from here: > http://libcxx.llvm.org) > > The std namespace is declared using (yet more) macros, this time > _LIBCPP_{BEGIN,END}_NAMESPACE_STD. I believe these aren't parsed > correctly, so the declarations end up in the global namespace. Note that > the definition itself uses the "inline namespace" feature of C++11: > > #define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace > _LIBCPP_NAMESPACE { > #define _LIBCPP_END_NAMESPACE_STD } } > > > libc++ uses visibility macros such as _LIBCPP_INLINE_VISIBILITY and > _LIBCPP_TYPE_VIS_ONLY. These resolve to attibute declarations such as: > > #define _LIBCPP_TYPE_VIS __attribute__ > ((__type_visibility__("default"))) > > > This, or perhaps something else, prevents the vector template > declaration being parsed. The declaration itself is this: > > template <class _Tp, class _Allocator = allocator<_Tp> > > class _LIBCPP_TYPE_VIS_ONLY vector > : private __vector_base<_Tp, _Allocator> > { > // contents elided > }; > > > Which is parsed as: > > ("__vector_base" variable > (:type "int") > nil #<overlay from 17184 to 31629 in vector>) > > > I think there are also other parsing issues relating to the use of > _NOEXCEPT_ macros - but my main problem right now is to get the vector > declaration parsed correctly. > > Please let me know if more information is needed. > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > > > > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: David E. <de...@ra...> - 2014-04-30 06:41:16
|
Eric M. Ludlam writes: > The preprocessor in CEDET can't handle macros with open { in them using > the typical declarative mechanism. It should be able to parse that; I added that feature a few months ago. I think the problem is the 'inline namespace', which is C++11. Cheers, David |
From: Eric M. L. <er...@si...> - 2014-04-30 11:28:25
|
On 04/30/2014 02:41 AM, David Engster wrote: > Eric M. Ludlam writes: >> The preprocessor in CEDET can't handle macros with open { in them using >> the typical declarative mechanism. > > It should be able to parse that; I added that feature a few months ago. Oh, I missed that! Can we remove the other lexical hacks for namespaces then? Thanks Eric |
From: David E. <de...@ra...> - 2014-05-01 10:37:06
|
Eric M. Ludlam writes: > On 04/30/2014 02:41 AM, David Engster wrote: >> Eric M. Ludlam writes: >>> The preprocessor in CEDET can't handle macros with open { in them using >>> the typical declarative mechanism. >> >> It should be able to parse that; I added that feature a few months ago. > > Oh, I missed that! Can we remove the other lexical hacks for > namespaces then? Probably. I did not want to risk it for the upcoming 24.4 release, but let's do that when it is released. Cheers, David |