r196407 - Enea Zaffanella's fix for the PPCallbacks Elif callback, with a slight re-org, and an update of the new PPCallbacks test (soon to be moved to clang from extra), rather the unittest.

[Enea Zaffanella]

On 12/04/2013 09:35 PM, Thompson, John wrote:
> Hi Enea,
>
> Thank you for fixing the Elif callback call in PPCallbacks.  This checkin (r196407) contains your fix (with a minor rearrangement), except that rather than use your change to the PPCallbacks unit test, I update the pp-trace test to test this, which is in the related clang-tools-extra checkin.  I will soon be moving this tool and test to clang, unless someone objects.
>
> -John

Thank you.

If you are currently looking at PPCallbacks, I would like to point out 
the following:

   /// \brief Hook called whenever an \#elif is seen.
   /// \param Loc the source location of the directive.
   /// \param ConditionRange The SourceRange of the expression being tested.
   /// \param ConditionValue The evaluated value of the condition.
   /// \param IfLoc the source location of the \#if/\#ifdef/\#ifndef 
directive.
   // FIXME: better to pass in a list (or tree!) of Tokens.
   virtual void Elif(SourceLocation Loc, SourceRange ConditionRange,
                     bool ConditionValue, SourceLocation IfLoc) {
   }

Here it is said that ConditionValue holds the evaluated value of the 
condition.
However, this callback is also invoked when we already have taken a previous
(#if or #elif) branch and in this case the condition is not evaluated at 
all.
Hence, the boolean value passed to the callback is just meaningless.
This happens in method:

     void Preprocessor::HandleElifDirective(Token &ElifToken)

I was wondering if a further boolean parameter to the callback 
(IsConditionEvaluated or similar) would be the simplest approach to let 
the clients know whether or not they should trust the value passed in 
parameter ConditionValue.

Enea.