[cfe-commits] [patch] Support decltype in pseudodestructor/dependent destructor calls

[David Blaikie]

On Mon, Dec 12, 2011 at 12:25 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Mon, Dec 12, 2011 at 11:18 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Sun, Dec 11, 2011 at 8:27 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>> Here's the finishing touches on decltype in explicit destructor calls
>>> - supporting pseudodestructor calls and destructor calls on dependent
>>> types (which are handled by Clang in a similar way to pseudodestructor
>>> calls):
>>>
>>> typedef int foo;
>>> foo f;
>>> f.~decltype(foo())();
>>>
>>> template<typename T>
>>> void func(T* t) {
>>>  t->~decltype(T())();
>>> }
>>>
>>> etc...
>>
>> Patch looks fine.
>
> Thanks Eli - actually, as I was going to check this in & remembered
> I'd wanted to refactor the arrow-testing logic I'd shamelessly
> copy-pasted from one of the other pseudo-destructor parsing functions.
> (it tests for arrow uses that should be '.') See
> SemaExprCXX.cpp:4327-4345, repeated at 4445-4463, and then repeated
> again in my patch.
>
> I moved this logic into a common, static, utility function - but then
> I got thinking. How/when does this actually occur? Since
> pseudodestructors can destroy any object, it seems impossible for us
> to ever correctly diagnose an erroneous '->' that should be a '.'
> before we've seen the type on the right of the '~'. So I replaced the
> diag+fixit with an assertion & ran the test suite. It never fires.
>
> I tested the following for cases:
>
> struct foo { void bar(); };
> void func(foo* f, foo& g) {
>  f.~foo();
>  f->~foo();
>  g.~foo();
>  g->~foo();
> }
>
> and none of them produce the -> fixit:
>
> arrow.cpp:3:6: error: the type of object expression ('foo *') does not
> match the type being destroyed ('foo') in pseudo-destructor
>      expression
>  f.~foo();
>  ~  ^~~
> arrow.cpp:6:4: error: member reference type 'foo' is not a pointer
>  g->~foo();
>  ~^
>
> It seems this code is dead, so far as I can tell. Should I delete the
> existing two instances of it & remove the one I was going to add to my
> code?

Revised patch with this refactoring attached. I had to keep the first
bit so we could find the right base type if it was a -> or ., but
that's only 3 lines. I still put this in a common function to be used
by all 3 spots that need this logic.

- David

> (if we wanted to do something fancy we could wait until after we've
> parsed the rhs & if the mismatch between base left and right is only
> by pointer then we could issue the fixit to switch -> to . or the
> other way around, if we think that's the right thing to do (I think
> it's hard to guess which one the user really intended - whether they
> meant to destroy the pointer or pointee... so I'm not sure if we
> should guess))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr10127-pseudo-dtor.diff
Type: application/octet-stream
Size: 8596 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111212/2770309b/attachment.obj>