On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> But sure, if you prefer the COLON_SCOPE version of the patch, I can commit
> that. There is no PREV_WHITE in the preprocessor, there is
Yes, I prefer the COLON_SCOPE version.
--
Joseph S. Myers
josmy...@redhat.com
On Thu, Feb 22, 2024 at 05:49:12PM +, Joseph Myers wrote:
> This patch (the one using COLON_SCOPE, *not* the one using PREV_WHITE) is
> OK.
>
> PREV_WHITE is about whether there is whitespace between the tokens in the
> macro expansion, for the purposes of stringization - I don't think it's
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
> and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
> or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
> there are i
Hi,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> > Hmm, shouldn't you be able to use (nonexistence of) the PREV_WHITE flag on
> > the second COLON token to see that it's indeed a '::' without intervening
> > whitespace? Instead of setting a new flag on the first COLON token?
> >
> > I.e. somet
On Thu, Feb 22, 2024 at 03:59:31PM +0100, Michael Matz wrote:
> Hello,
>
> On Thu, 22 Feb 2024, Jakub Jelinek wrote:
>
> > So, the following patch adds a flag during preprocessing at the point
> > where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> > on the first CPP_COLON to
Hello,
On Thu, 22 Feb 2024, Jakub Jelinek wrote:
> So, the following patch adds a flag during preprocessing at the point
> where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> on the first CPP_COLON to mark the consecutive case (as we are tight
> on the bits, I've reused the PU
Hi!
We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
there are is just a pair of CPP_COLON tokens.
The c-lex.cc hunk ad
