This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,c++] provide intelligent error messages for missing semicolon after class definition


On Fri, Nov 19, 2010 at 03:06:52PM +0000, Joseph S. Myers wrote:
> On Fri, 19 Nov 2010, Nathan Froyd wrote:
> > +/* Return true if KEYWORD names a storage class specifier.  */
> > +
> > +bool
> > +keyword_is_storage_class_specifier (enum rid keyword)
> > +{
> > +  switch (keyword)
> > +    {
> > +    case RID_CONST:
> > +    case RID_VOLATILE:
> > +    case RID_INLINE:
> > +    case RID_RESTRICT:
> 
> Not storage class specifiers in C (const, volatile and restrict are type 
> qualifiers, inline is a function specifier).  However, typedef is a 
> storage class specifier in C.  And so in C1X is _Thread_local - I imagine 
> we'll end up making both __thread and _Thread_local use RID_THREAD and 
> having GCC accept all the cases that are valid according to C1X (plus any 
> other existing GNU cases unless -pedantic) rather than having distinct 
> rules for the two spellings.

I admit to playing a little loose with the name here.  C++ N1905, from
2005, says that:

- inline, virtual, and explicit are function specifiers [dcl.fct.spec];

- auto, register, static, extern, and mutable are storage class
  specifiers [dcl.stc];

- typedef and friend are decl specifiers [dcl.spec].

- I think [basic.type.qualifier] qualifies as making const and volatile
  type qualifiers; I assume we can shoehorn restrict in there as well.

(I do not have access to a more recent copy of the spec.)

Proposal:

- keyword_is_function_specifier, recognizing inline, virtual, and
  explicit above;

- keyword_is_type_specifier, recognizing const, volatile, and restrict;

These would go in c-common.  Is that non-controverisal?

Whatever recognizes `friend' should probably just go in the C++ front
end.

I don't know what to do about a common storage_class recognizer.  We
could either have the c-common function recognize the common subset (the
[dct.stc] identifiers above, plus RID_THREAD).  The C front-end would
then have to remember RID_TYPEDEF in appropriate places.  Or we could
silently stuff typedef in there and assume it will DTRT in C++.  Or we
can just give up on having that code shared between the C and C++ front
ends, and I'll put keyword_is_storage_class_specifier somewhere in the
C++ front end.  WDYT?

-Nathan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]