Bug 213449 - [WTF] Ensure ASCIILiteral is ASCII characters at compile time
Summary: [WTF] Ensure ASCIILiteral is ASCII characters at compile time
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-06-21 19:07 PDT by Yusuke Suzuki
Modified: 2020-06-22 08:17 PDT (History)
9 users (show)

See Also:


Attachments
Patch (2.87 KB, patch)
2020-06-21 19:09 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2020-06-21 19:07:33 PDT
[WTF] Ensure ASCIILiteral is ASCII characters at compile time
Comment 1 Yusuke Suzuki 2020-06-21 19:09:16 PDT
Created attachment 402438 [details]
Patch
Comment 2 Ross Kirsling 2020-06-21 19:25:38 PDT
Comment on attachment 402438 [details]
Patch

r=me. ラーメン食べたい。
Comment 3 Mark Lam 2020-06-21 19:33:36 PDT
Comment on attachment 402438 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=402438&action=review

> Source/WTF/wtf/text/ASCIILiteral.h:64
> +        ASSERT_UNDER_CONSTEXPR_CONTEXT(isASCII(characters[i]));

Since this is constexpr, is there a reason why we only want this for ASSERT_ENABLED?  Why not have RELEASE_ASSERT_UNDER_CONSTEXPR_CONTEXT this?
Comment 4 Yusuke Suzuki 2020-06-21 19:58:17 PDT
Comment on attachment 402438 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=402438&action=review

>> Source/WTF/wtf/text/ASCIILiteral.h:64
>> +        ASSERT_UNDER_CONSTEXPR_CONTEXT(isASCII(characters[i]));
> 
> Since this is constexpr, is there a reason why we only want this for ASSERT_ENABLED?  Why not have RELEASE_ASSERT_UNDER_CONSTEXPR_CONTEXT this?

Discussed with Mark on Slack, this function can be called in non-constexpr context, like,

auto string = "Hey"_s; // instead of constexpr string = "Hey"_s; in non global code.

So, this is safer for accidental runtime checks.
Comment 5 EWS 2020-06-21 23:51:32 PDT
Committed r263341: <https://trac.webkit.org/changeset/263341>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 402438 [details].
Comment 6 Radar WebKit Bug Importer 2020-06-21 23:52:17 PDT
<rdar://problem/64585669>
Comment 7 Adrian Perez 2020-06-22 00:23:32 PDT
Comment on attachment 402438 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=402438&action=review

> Source/WTF/ChangeLog:12
> +            auto globalVariable = "ã©ã¼ã¡ã³ (Ramen in Japanese)"_s;

As a ramen enthusiast, I like this example in the commit log ^_^ 🍜️♥️
Comment 8 Darin Adler 2020-06-22 07:50:48 PDT
Very very happy to see this change go in.
Comment 9 Darin Adler 2020-06-22 08:10:43 PDT
Is there some way to make this even more strongly guaranteed to be done at compile time? I assume the answer is no, but obviously we want to compile errors with a poorly formed literal, not a runtime check if it happens to be used in a non-constexpr context.
Comment 10 Yusuke Suzuki 2020-06-22 08:17:19 PDT
(In reply to Darin Adler from comment #9)
> Is there some way to make this even more strongly guaranteed to be done at
> compile time? I assume the answer is no, but obviously we want to compile
> errors with a poorly formed literal, not a runtime check if it happens to be
> used in a non-constexpr context.

This is the purpose of consteval in C++20!
https://en.cppreference.com/w/cpp/language/consteval

I can't wait to use C++20 :D