Proposed resolution (June, 2019):

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

Each has-attribute-expression is replaced by a non-zero pp-number matching the form of an integer-literal if the implementation supports an attribute with the name specified by interpreting the pp-tokens, after macro expansion, as an attribute-token, and by 0 otherwise. The program is ill-formed if the pp-tokens do not match the form of an attribute-token.

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

After all replacements due to macro expansion and evaluations of defined-macro-expressions, and has-include-expressions, and has_attribute_expressions have been performed, all remaining identifiers and keywords, except for true and false, are replaced with the pp-number 0, and then each preprocessing token is converted into a token. [Note: An alternative token (5.5 [lex.digraph]) is not an identifier, even when its spelling consists entirely of letters and underscores. Therefore it is not subject to this 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 same macro as the argument to __has_cpp_attribute and get the corresponding 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 tested to see if it names an attribute or not, and there is implementation divergence.