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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to