[PATCH] D105759: Implement P2361 Unevaluated string literals

Fri Jul 28 10:48:28 PDT 2023

hubert.reinterpretcast added a comment.

In D105759#4541813 <https://reviews.llvm.org/D105759#4541813>, @cor3ntin wrote:

> In D105759#4540716 <https://reviews.llvm.org/D105759#4540716>, @hubert.reinterpretcast wrote:
>
>>> I hope this patch may allow to gather some data on that.
>>
>> @cor3ntin, I have reports that applications having encoding prefixes in `static_assert` are failing to build. The committee did not adopt the subject paper as a "DR resolution". Is it possible to downgrade to a warning?
>
> You know how frequent it is?

No, but I am concerned that this came up even before we deployed an LLVM 17-based solution (in pre-release testing). I believe that reverting for LLVM 17 is the prudent course of action.

> Previously with a prefix, it was parsed as a wide (for example) string, and we relied on the fact that L was UTF-16/32 to sometimes print a reasonable diagnostics - and sometimes not https://godbolt.org/z/f3Pj4T5aj
> This is going to be worse when we add -fexec-charset:
>
> - `static_assert(true, L"やあ")` is going to be ill-formed when coded as, eg, EBCDIC because it's not representable, and if it is representable we need to either output mojibake or convert the string back to UTF-8 which we are currently not doing.

This may be the motivation for the prefixes in the applications in the first place in the context of other compilers: They may have needed the prefix to avoid unrepresentable character issues (e.g., if the other compiler rejects the unprefixed string, but manages to emit the error to the terminal because both the terminal and the compiler use the source encoding).

> Another solution maybe to lexically ignore prefixes by replacing the string literal token on the fly such that they are still parsed as unevaluated strings and not encoded, i could look into that.

This sounds good.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105759/new/

https://reviews.llvm.org/D105759