[cfe-commits] [patch] Disallow decltype in qualified declarator-ids

[David Blaikie]

On Mon, Dec 12, 2011 at 11:53 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Dec 12, 2011 at 11:18 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> 8.3\1 dcl.meaning states:
>> "The nested-name-specifier of a qualified declarator-id shall not
>> begin with a decltype-specifier."
>>
>> & this patch implements that, disallowing things like:
>>
>> struct foo {
>>  static int i;
>> };
>>
>> int decltype(foo())::i;
>>
>> The source range in the error message isn't perfect (due to the
>> unaddressed fixme in DecltypeTypeLoc - it doesn't have the full source
>> range, just the location of the 'decltype' keyword. I'll address this
>> separately) & I haven't provided a fixit for this at the moment (it'd
>> be possible to suggest replacing the decltype with the actual
>> qualified name, at least for now -I'm not sure what we'll be doing
>> about unnameable types that come with lambdas, though).
>
> I don't think lambdas are really relevant here: I can't think of a way
> to write a legal declaration starting with a decltype of a lambda
> type.

Ah, right - I'd sort of gone off on a tangent there just thinking
about unnameable types in general. Though it could still be relevant
here - you might specialize a template with a lambda argument

template<typename T>
struct foo {
  void bar();
};
auto i = [](){};
foo<decltype(i)> func();
template<>
void decltype(func())::func() {
}

but at least there you've referred to the type in /some/ way so that
could be used, but perhaps in other cases it might not be so obvious.

> That said, I don't think there's a reliable way to FIXME out of
> this, short of inserting a typedef: what if the decltype is dependent,
> or refers to a user-defined unnamed struct type?

Ah, indeed - there are other anonymous types already without invoking lambdas.

Still, might be nice to fixme the cases that can be easily named - but
perhaps I'm being unrealistic. I've got enough other things to tidy
up/work on that I don't really need to be worrying about that anyway
:)

> The patch looks fine otherwise.

Thanks again. Committed as r146480,
- David