CWG3016 [cpp.cond] `__has_include` diagnosable rule re: syntax that is impossible to violate

[hubert-reinterpretcast]

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): cpp.cond

Link to reflector thread (if any): N/A

Issue description:
https://wg21.link/cpp.cond#4 says:

The header or source file identified by the parenthesized preprocessing token sequence in each contained has-include-expression is searched for as if that preprocessing token sequence were the pp-tokens in a #include directive, except that no further macro expansion is performed. If such a directive would not satisfy the syntactic requirements of a #include directive, the program is ill-formed.

Such a directive would always satisfy the syntactic requirements of a #include directive, because #include syntactically accepts pp-tokens (https://wg21.link/cpp.include#4).

Suggested resolution:

If the preprocessing token sequence does not consist solely of a header-name or cannot be combined ([cpp.include]) into a single header-name preprocessing token, the program is ill-formed.

[jensmaurer]

Beyond the unfortunate "syntactic requirements" phrasing, this is only a problem because [cpp.include] p4 says

"If the directive resulting after all replacements does not match one of the two previous forms, the behavior is undefined."

(note "undefined") instead of ill-formed, right?

Otherwise, __has_include could just delegate to [cpp.include] and possibly get an ill-formed attempt to form a header-name there.

[hubert-reinterpretcast]

Otherwise, __has_include could just delegate to [cpp.include] and possibly get an ill-formed attempt to form a header-name there.

Agreed. That's why this is not a problem for __has_embed (and why the parallel wording for __has_embed is potentially redundant).

[jensmaurer]

CWG3016