[cfe-commits] [patch] Support decltype in destructor calls

[David Blaikie]

On Wed, Dec 7, 2011 at 3:44 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Dec 7, 2011 at 3:07 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> Here's a small patch to implement the use of decltype in (non-pseudo)
>> destructor calls like so:
>>
>> struct foo { };
>> void func(foo* f) {
>>  f->decltype(*f)();
>> }
>>
>> I thought I'd send this out as a small, easier to digest code review,
>> even though it doesn't cover all cases (the most obvious/useful cases
>> are in templates with dependent types in the expression. The problem
>> there is that clang parses those conservatively as pseudo destructor
>> calls & it'll take a bit more work to plumb this solution through that
>> code).
>
>
> +ParsedType Sema::getDestructorType(const DeclSpec& DS, ParsedType ObjectType) {
> +    if (DS.getTypeSpecType() == DeclSpec::TST_error)
> +      return ParsedType();
> +    assert(DS.getTypeSpecType() == DeclSpec::TST_decltype
> +           && "only get destructor types from declspecs");
> +    QualType T = DS.getRepAsExpr()->getType();
>
> You can't just use getType() here; you need Sema::BuildDecltypeType().
>  This causes some minor issues: specifically, your testcase that does
> "x->~decltype(*x)();" isn't actually valid.

Ah, right, decltype(*x) being A& instead of A. Fixed that & added some
cases/modified the existing diagnostics (now that it uses a decltype
type the diagnostics are a bit more clear about the type & how it was
specified). Thanks.

> Also, I think you need to check if the T is dependent.

Hmm - I've tried a few things, but I think that's not an issue for
now. It seems like any dependent type on the left of the '.' or '->'
goes through the pseudo destructor path (see
Sema::ActOnStartCXXMemberReference - first thing it does is check if
it's a dependent type and sets MayBePseudoDestructor to true). So if
the rhs is dependent we'll just get a mismatch at the moment since the
lhs is never dependent.

Unless I'm missing something - perhaps there's a more specific case
you had in mind?

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr10127-dtor.diff
Type: text/x-diff
Size: 4216 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111207/3205fb1b/attachment.diff>