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

[Aaron Ballman]

On Tue, Jan 15, 2013 at 5:46 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Wed, Jan 16, 2013 at 12:37 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> This patch addresses PR14837, so that __has_include and
>> __has_include_next do not work outside of preprocessor directives.
>> This fixes a failing assertion, as well as clarifies the behavior (I
>> can update the public docs if we think it's desirable).  Patch
>> Includes test cases.
>
> Mechanical issues:
>
> +      if (PP.getCurrentLexer()->isParsingPreprocessorDirective())
>        PP.getCurrentLexer()->LexIncludeFilename(Tok);
> +      else {
>
> Indentation is funny on the "PP" line.
>
> +        PP.Diag( SLoc, diag::err_pp_directive_required ) << II->getName();
>
> No spaces after "(" and before ")", please.

Good catches.  I'll resolve both.

> Why not reject these cases with error at the very beginning of the
> function or in the caller, Preprocessor::ExpandBuiltinMacro?

My original thinking was in case it was ill-formed in other ways, but
that was when I was thinking this would be a warning instead of an
error. I can certainly move it up if that lends clarity.

Thanks!

~Aaron