https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
--- Comment #8 from Halalaluyafail3 <luigighiron at gmail dot com> ---
(In reply to Andrew Pinski from comment #6)
> Because otherwise it would mean:
> ```
> [[ignored(
> #)]]int main(){}
> ```
>
> Would be invalid C while:
> ```
> [[ignored(#)]]int main(){}
> ```
>
> Would be valid. That is white space of a return would matter which I am not
> sure is the expected behavior at all.
The preprocessor is whitespace sensitive, so I don't see it as surprising. If
one wanted to write it on two lines like that they could define a macro NONE
like so:
#define NONE
Expanding this macro before the # would cause it to not be interpreted as a
directive.
> The way I read the standard is the following:
> during phase 4:
> Preprocessing directives are executed,
>
> And it is invalid for `#` or the `##` operator to be outside of `the
> replacement list of a function-like macro,` as far as I can tell during
> phase 4.
This interpretation would forbid the hash_hash example that is in the standard.
Also, GCC doesn't diagnose #, ##, %:, and %:%: being used in other contexts
during preprocessing. For example when just preprocessing (-E) the original
example of [[ignored(##)]] does not generate any errors, the error only occurs
during compilation. If your interpretation is correct, shouldn't an error be
generated during preprocessing instead of compilation?
