https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |17.0
--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
Looking at this again
- it is a long-standing issue that has needed many hacks to work around it and
some of those hacks (e.g. fixincludes) are not applicable to all cases.
I would like this to get resolved for GCC-17, it is getting increasingly
difficult to support Darwin SDKs without out-of-tree fixes.
The underlying issue is that the lexer is 'greedy' in tokenisation - thus it
decides from 'N.' that the token is a floating point number and then rejects
N.M.O as invalid.
This applies equally to the __attribute__ and [[ ]] form.
We have no standardisation rules for the former, but both C and C++ standard
attribute state that attribute arguments are " a balanced token sequence ".
N.M.O can form part of a balanced token sequence and so for C++ and C23
attributes we should consume the problematical attributes in their current
form.
NOTEs
* For the C front end, since flexing is done on demand, it is possible to make
a contextual switch to consume attribute arguments as a string which I have
done as a work-around. This works for both GNU-style and standard attributes
without jumping through too many hoops.
* For C++ it is much more complex, since the flexing is done in advance. For
GNU-style attributes it is possible to build a state machine that does a
similar switch to consume attribute arguments as a string. However, for the
standard form this becomes horrendously complex.
* for the C++ FE is also means that syntax error messages for FP cases are
emitted far away from the position that the parser finally encounters them (I
know we do not have complete ordering of diagnostics anyway - but in this case
the separation can be very large - which is not especially user-friendly.
Ideas:
- if we encounter a prospective FP number that then fails continuation, but is
still a valid token sequence - back off and tokenise it in the second form
- defer FP tokenisation until the position at which it is consumed
