On Wed, Nov 10, 2021 at 09:30:29PM +0000, Joseph Myers wrote:
> On Wed, 10 Nov 2021, Tobias Burnus wrote:
>
> > Disclaimer: While this patch does a step into the right direction,
> > it probably does help with any of the other _Pragma issues. Neither
> > with 'gcc -E' when the pragma wasn't registered (still expanded too
> > early) nor with the 'GCC diagnostic' issues in general as there the
> > input_location is used to decide when to pop - and depending on the
> > column numbers, this may or may not work.
>
> And fully correct stringization of _Pragma should respect the spelling of
> the preprocessing tokens (of the string-literal preprocessing token, that
> is; spelling variations for the other preprocessing tokens aren't possible
> here) and the presence or absence of whitespace between them.
>
> _Pragma("foo")
> _Pragma ("foo")
> _Pragma("foo" )
> _Pragma(L"foo")
> _Pragma ( "foo" )
>
> (for example) should all have their spelling preserved by stringization
> (but any nonempty white space sequence becomes a single space).
Yeah. And not just that, I think also all the exact whitespace in the
string literal (this time with no replacement of nonempty white space with a
single space).
Consider in pragma-3.c e.g.
#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity
(warning) message (\"Test\") at(compilation)" )
should yield:
const char *str = "\"1,2\" ; _Pragma ( \" omp error severity
(warning) message (\\\"Test\\\") at(compilation)\" )";
I guess we could encode the PREV_WHITE flags from the ( and ) tokens as 2
separate
bits somewhere (e.g. in some bits of the pragma id), but we need to encode the
whole
string literal somewhere too.
Now, in cpp_token we have:
union cpp_token_u {
/* Caller-supplied identifier for a CPP_PRAGMA. */
unsigned int GTY ((tag ("CPP_TOKEN_FLD_PRAGMA"))) pragma;
}
where several other members of the union are structs, either with a pair
of unsigned and pointer or two pointers. So, could we make
the pragma union member also a struct with the pragma id and
pointer to the _Pragma string literal cpp_token?
Though, that doesn't solve the case where in destringize_and_run
pfile->directive_result.type != CPP_PRAGMA.
Are we handling the pragma at a wrong phase of preprocessing?
Jakub
