[clang] Fully support #embed in C++

[cor3ntin]

https://wg21.link/P1967

Ideally we would just have to remove/adapt the extension warnings

@Fznamznon

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: cor3ntin (cor3ntin)

https://wg21.link/P1967

Ideally we would just have to remove/adapt the extension warnings

@Fznamznon

[Fznamznon]

Do we need to enable embed in C++26 without warnings and emit a compat warning for older versions?

[cor3ntin]

Do we need to enable embed in C++26 without warnings and emit a compat warning for older versions?

Yes

[frederick-vs-ja]

There seems to be a design change (expand everything after the #embed, not just the argument list) after merging #68620.
CC @ThePhD.

[ThePhD]

Yes. This was based on feedback from implementers in the room (Clang, GCC, MSVC, and (via e-mail) elLipse) that this was preferable to the initial specification, because forward-parsing for the exact form while only expanding what was inside arguments was a "pain in the ass" and "a nightmare to [implement]".

So it was changed in accordance with their wishes.

[Endilll]

In Sofia CWG discussed the following Core issues that touch#embed:
CWG3013 "Disallowing macros for #embed parameters"
CWG3014 "Comma-delimited vs. comma-separated output for #embed"
CWG3015 "Handling of header-names for #include and #embed"
CWG3016 "Satisfying the syntactic requirements of #include and #embed"
CWG3018 "Validity of defined in __has_embed"
CWG3019 "Restrictions on character sequences in header-names"