[cfe-commits] r59502 - in /cfe/trunk: Driver/ include/clang/Analysis/ include/clang/Analysis/PathSensitive/ include/clang/Basic/ include/clang/Driver/ lib/Analysis/ lib/Basic/ lib/CodeGen/ lib/Driver/ lib/Lex/ lib/Parse/ lib/Sema/

Sebastian Redl sebastian.redl at getdesigned.at
Tue Nov 18 00:46:15 PST 2008


Chris Lattner wrote:
> This is a somewhat tricky dance, but it means that the 
> accumulated DiagnosticInfo is allowed to keep pointers to other expression 
> temporaries without those pointers getting invalidated.
>   
Are you sure? If the DiagnosticInfo is constructed earlier than the 
other temporaries, wouldn't it be destroyed *after* them?
Look at this short example I've written, which is similar in mechanism 
to your code:

#include <iostream>

struct Sink
{
        bool hadInput;
        Sink() : hadInput(false) {}
        ~Sink() { if(hadInput) std::cerr << "Sink with input 
destructing\n"; }

        template <typename T>
        Sink& operator << (const T&) { hadInput = true; return *this; }
};

struct Sentry
{
        ~Sentry() { std::cerr << "Sentry destructing\n"; }
};

Sink makeSink()
{
        return Sink();
}

int main()
{
        makeSink() << Sentry();
}


It does the right thing on my compiler, but is this guaranteed? It also 
creates the Sentry object before calling makeSink, and that's not 
something to be relied on if Sentry is a heavy object.

> We will soon be able to just do:
>
>   Diag(BuiltinLoc, diag::err_overload_no_match)
>       << typeNames << SourceRange(BuiltinLoc, RParenLoc));
>
> This scales better to support arbitrary types being passed in (not just 
> strings) in a type-safe way.  Go operator overloading?!
>   
This is great.

Sebastian



More information about the cfe-commits mailing list