Question about existing tests for [dcl.stc]

[Richard Smith]

On Mon, May 19, 2014 at 2:38 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Mon, May 19, 2014 at 5:32 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > You're citing the wrong section of the standard in your patch. The
> relevant
> > wording is [dcl.stc]p1: "If a storage-class-specifier appears in a
> > decl-specifier-seq, [...] the init-declarator-list of the declaration
> shall
> > not be empty [...]."
>
> Ah, good to know. I made it down to p9 because we were declaring a
> type instead of a member variable, but that makes sense.
>
> > Do we really need to change the code here? Is the new diagnostic better
> than
> > the old one?
>
> Old diagnostic: ext-warn "'mutable' is not permitted on a declaration of a
> type"
> Proposed diagnostic: error "'mutable' can only be applied to member
> variables"
>
> Honestly, either works for me in terms of wording.
>
> > Do we have a reason to promote this from ExtWarn to Error just
> > for mutable and not for other storage class specifiers?
>
> I was going with error because the other mutable constraint violations
> are also errors (including this existing one which I was reusing).
> Also, it seems weird to treat this as an extension -- what does this
> extension actually provide in terms of benefit for the mutable
> keyword? What does a mutable type declaration even mean?


It's weird that we allow this for other storage classes too. What does a
static type declaration mean? =)

No objection to the patch; I think I slightly prefer consistent treatment
of 'mutable' over consistent treatment of storage classes on type
declarations. But I wonder why we ExtWarn rather than Error'ing here in the
other cases, and I'm slightly cautious about changing this without knowing
the history.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140522/7c7a974d/attachment.html>