[cfe-commits] [PATCH] Disallow __has_include and __has_include_next outside of preprocessor directives

[Aaron Ballman]

On Wed, Jan 16, 2013 at 10:33 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Wed, Jan 16, 2013 at 3:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> This patch moves the logic around slightly to handle macros better;
>> instead of relying on the PP Lexer, we track the information in the PP
>> itself so that is is always available.  I've expanded the test cases
>> to cover macros more fully.
>
>  void Preprocessor::HandleIfDirective(Token &IfToken,
>                                       bool ReadAnyTokensBeforeDirective) {
> +  ParsingPreprocessorDirective = true;
>    ++NumIf;
>
>    // Parse and evaluate the conditional expression.
> @@ -2101,6 +2102,7 @@
>      SkipExcludedConditionalBlock(IfToken.getLocation(), /*Foundnonskip*/false,
>                                   /*FoundElse*/false);
>    }
> +  ParsingPreprocessorDirective = false;
>  }
>
> We have llvm/Support/SaveAndRestore.h to simplify this.

That's neat, I didn't notice we had that.  However, using that would
mean I couldn't use a bit-field for the property either (due to
requiring a reference).  So the question I have is: which is "better"?
 Given that we already have several other boolean bitfields, I am on
the fence.

> +  /// \brief Returns true if currently parsing a preprocessor directive
> +  bool isParsingPreprocessorDirective() const {
> +    return ParsingPreprocessorDirective;
> +  }
>
> +  /// \brief True if we are currently preprocessing a #if or #elif directive
> +  bool ParsingPreprocessorDirective : 1;
>
> Please synchronize these two comments, and maybe rename to
> ParsingIfOrElifDirective.

Can do.

Thanks!

~Aaron