This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-10-26

2390. Is the argument of __has_cpp_attribute macro-expanded?

Section: 15.2  [cpp.cond]     Status: CD5     Submitter: Richard Smith     Date: 2018-11-14

[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.

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.

Proposed resolution (June, 2019):

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

    2. 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:

    3. 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]