Hi John,
There are a range of different syntax that don't work in the semantic
parser. If you look in c.by, there are a bunch listed in the header
comment as still todo. I'm not sure which may have since been fixed
without fixing the comments.
As I look in the parser, I see that many rules look like this:
declmods typeformbase cv-declmods opt-ref ....
and then when assigning parts:
:constant-flag (if (member "const" (append $1 $3)) t nil)
:typemodifiers (delete "const" (append $1 $3))
so the ordered nature of those lists WRT where the datatype is is lost.
For the methods in a class, it does appear that it is using a different
style for parsing cvq than global symbols, and at the moment it is
inscrutable to me.
I think one of the dilemmas is that the primary purpose of the parser
for many people is completion, which only needs to base data type, and
generally ignores the CVQs. I can certainly imagine many useful tools
reminding you of inconsistencies if they were tracked properly.
Getting things to line up with the format functions seems like a helpful
thing, which is probably pretty easy so long as the data is available.
I think that what this area really needs a some testing infrastructure
with some language files that parses the file then formats the tags, and
makes sure that the raw text matches up. We'd then have a good forum
for making sure we can fix up the parser and lock down the behavior.
I think many of these issues have been ignored as there has been a goal
to move the C parser from the current parser infrastructure to the
wisent parser for performance reasons, but that obviously hasn't
happened yet. We are probably better off spending time making the
current thing more accurate.
Of course, this all depends on someone having the time to tackle this
problem. Any volunteers out there?
Eric
On 02/28/2012 11:18 PM, John Yates wrote:
> I have been playing with the canned semantic-format-tag-functions when
> dealing with C++ types to see how close to a fully "demangled"
> presentation I can achieve. This note reports observations on both
> the parsing and the displaying of const or volatile qualifiers
> (hereafter termed 'cvq').
>
> 1) leaf-level cvq does not seem to get recorded if it appears in the
> canonical rightmost position:
> cvq foo* bar; => "cvq foo* bar"
> foo cvq* bar; => "foo* bar"
>
> 2) cvq further up a type tree is missing (unsure if this is a
> recording or a display issue):
> cvq foo* cvq bar() => "cvq foo* bar ()"
>
> 3) argument cvq handled properly in either position so long as formal
> parameter name is present:
> void W(cvq foo* bar); => "void W (cvq foo* bar)"
> void X(foo cvq* bar); => "void X (cvq foo* bar)"
>
> 4) argument cvq missing irrespective of position if no formal
> parameter name is present
> void Y(foo cvq*); => "void Y (foo*)"
> void Z(cvq foo*); => "void Z (foo*)"
>
> 5) argument cvq further up type tree is missing irrespective of
> presence of formal parameter name:
> void P(foo* cvq bar); => "void P (foo* bar)"
> void Q(foo cvq* cvq bar); => "void Q (cvq foo* bar)"
> void R(cvq foo* cvq bar); => "void R (cvq foo* bar)"
> void S(foo* cvq); => "void S (foo*)"
> void T(foo cvqt* cvq); => "void T (foo*)"
> void U(cvq foo* cvq); => "void U (foo*)"
>
> 6) cvq lost on methods:
> class C {
> void M(); => "void M ()"
> void M() const; => "void M ()"
> };
>
> 7) asymetic display ordering of cvq versus storage class (extern,
> static, register, etc):
> extern const foo* XC(); => "const extern foo* XC ()"
> extern volatile foo* XV(); => "extern volatile foo* XV ()"
>
>
> Final comment: I am a big believer in the virtue of consistently
> placing cvq in the canonical rightmost position (e.g. "int const i"
> rather than "const int i" and "char const* p" rather than "const char*
> p") . Thus I would be very grateful if there were an option to choose
> such formatting. (As an erstwhile compiler writer I will venture that
> if you teach your display functions to display cvq anywhere in a type
> then such formatting would be the default behavior and moving cvq to
> the left would require some additional special case logic. :-)
>
> /john
>
> ------------------------------------------------------------------------------
> Virtualization& Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
|