Is the argument of __has_cpp_attribute macro-expanded?
15.2 [cpp.cond]
Richard Smith

Created on 2018-11-14.00:00:00 last changed 20 months ago


Date: 2019-06-15.00:00:00

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.
  3. Change 15.2 [cpp.cond] paragraph 11 as follows:

  4. 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]
Date: 2019-02-15.00:00:00

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.

Date: 2019-07-15.00:00:00

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

Date User Action Args
2020-12-15 00:00:00adminsetmessages: + msg6429
2020-12-15 00:00:00adminsetmessages: + msg6428
2018-11-14 00:00:00admincreate