[cfe-dev] GCC's "Temporaries May Vanish Before You Expect"

[David Blaikie]

On Wed, Sep 12, 2012 at 4:32 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>
> On Sep 12, 2012, at 16:27 , David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Wed, Sep 12, 2012 at 4:10 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>> The thing that keeps me from removing it is that it IS more convenient and it CAN be made safe. The first way is to use C++11 to forbid the use of this function on rvalues; that looks like this:
>>>
>>>  template<class T> const T *getAs() const && = delete;
>>>  template<class T> const T *getAs() const & {
>>>    return dyn_cast<T>(this);
>>>  }
>>
>> Indeed, my thoughts precisely. [I wonder at what point it'll be worth
>> moving default development to C++11 and just keeping some bots around
>> for C++98 back compat testing.]
>>
>>> This could be hidden behind a compatibility macro:
>>>
>>>  template<class T> const T *getAs() const LLVM_RVALUE_DELETE;
>>>  template<class T> const T *getAs() const LLVM_LVALUE {
>>>    return dyn_cast<T>(this);
>>>  }
>>
>> What do you envision those macros being defined to in C++98? Wouldn't
>> you end up with errors relating to redeclaration of class members if
>> they expanded to nothing in C++98 builds.
>
> I guess I should have tried it first. I forgot you can't redeclare class members. :-(
>
>
>> Seems to me, unfortunately, like we'd have to #ifdef the extra
>> declaration entirely, or put the declaration inside a function-like
>> macro if possible, etc)
>
> Yes, that leaves something ugly like this:
>
> LLVM_LVALUE_ONLY(template<class T> const T *getAs() const) {
> }
>
> …and I don't even know how that would handle multiple template arguments. Bleah.

Yeah, given the infrequency of this particular idiom (we only have a
couple of these functions, right?) I think it'd still be worth adding
the extra declaration wrapped in an ifdef (& the LLVM_LVALUE could
still be used for the main declaration/definition) to catch these.

I've got a few extra buildbots to bring up at some point (or to
mix/match with the existing ones) a build-clang(&llvm)-as-C++11 will
be one of them.

>>> The second way is if -fcatch-undefined-behavior could be augmented to handle this case. I have no idea how to do this, though -- perhaps it requires something ASan-ish to poison the temporary memory once its lifetime ends.
>>>
>>> Any chance of either of these happening on trunk?
>>
>> +Richard Smith for the undefined behavior checking possibilities.
>