Movatterモバイル変換

Proposed resolution (June, 2019):

1. Change 15.2 [cpp.cond] paragraph 5 as follows:

Eachhas-attribute-expression is replaced by anon-zeropp-number matching the form ofaninteger-literal if the implementation supports anattribute with the name specified by interpretingthepp-tokens, after macro expansion,as anattribute-token, and by0otherwise. The program is ill-formed if thepp-tokensdo not match the form of anattribute-token.

2. Change 15.2 [cpp.cond] paragraph 11 as follows:

After all replacements due to macro expansion andevaluations ofdefined-macro-expressions,andhas-include-expressions,andhas_attribute_expressions have beenperformed, all remaining identifiers and keywords, exceptfortrue andfalse, are replaced withthepp-number0, and then each preprocessingtoken is converted into a token. [Note: Analternative token (5.9 [lex.digraph]) is not anidentifier, even when its spelling consists entirely ofletters and underscores. Therefore it is not subject tothis replacement. —end note]

Notes from the February, 2019 meeting:

CWG observed that a use of an attribute would be macro-expanded,so it seemed reasonable to expect to be able to specify the samemacro as the argument to__has_cpp_attribute and get thecorresponding result.

[Accepted as a DR at the July, 2019 meeting.]

The Standard does not specify whether the argument of__has_cpp_attribute is macro-expanded before being testedto see if it names an attribute or not, and there is implementationdivergence.