This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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