WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
180720
makeString: support more integral types
https://bugs.webkit.org/show_bug.cgi?id=180720
Summary
makeString: support more integral types
JF Bastien
Reported
2017-12-12 14:21:50 PST
I'm constantly trying to makeString of a size_t and it doesn't work. Fix it!
Attachments
patch
(15.84 KB, patch)
2017-12-12 14:27 PST
,
JF Bastien
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
JF Bastien
Comment 1
2017-12-12 14:27:19 PST
Created
attachment 329158
[details]
patch
JF Bastien
Comment 2
2017-12-12 14:28:00 PST
Comment on
attachment 329158
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=329158&action=review
> Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:84 > + EXPECT_EQ("hello * world", makeString("hello ", static_cast<unsigned short>(42) , " world")); // Treated as a character.
Note this! It's weird, but already pre-existed my patch! I'm just testing it now, and was surprised but I guess it makes sense given our odd 16-bit character types...
EWS Watchlist
Comment 3
2017-12-12 14:29:36 PST
Attachment 329158
[details]
did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:31: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 7 files If any of these errors are false positives, please file a bug against check-webkit-style.
WebKit Commit Bot
Comment 4
2017-12-12 16:50:37 PST
Comment on
attachment 329158
[details]
patch Clearing flags on attachment: 329158 Committed
r225824
: <
https://trac.webkit.org/changeset/225824
>
WebKit Commit Bot
Comment 5
2017-12-12 16:50:39 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 6
2017-12-12 16:51:29 PST
<
rdar://problem/36009251
>
Darin Adler
Comment 7
2017-12-13 09:37:32 PST
Comment on
attachment 329158
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=329158&action=review
>> Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:84 >> + EXPECT_EQ("hello * world", makeString("hello ", static_cast<unsigned short>(42) , " world")); // Treated as a character. > > Note this! It's weird, but already pre-existed my patch! I'm just testing it now, and was surprised but I guess it makes sense given our odd 16-bit character types...
I ran into this before in a patch I never landed. I think we should fix it by creating a different syntax for incorporating a single character in makeString.
JF Bastien
Comment 8
2017-12-13 09:43:45 PST
(In reply to Darin Adler from
comment #7
)
> Comment on
attachment 329158
[details]
> patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=329158&action=review
> > >> Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:84 > >> + EXPECT_EQ("hello * world", makeString("hello ", static_cast<unsigned short>(42) , " world")); // Treated as a character. > > > > Note this! It's weird, but already pre-existed my patch! I'm just testing it now, and was surprised but I guess it makes sense given our odd 16-bit character types... > > I ran into this before in a patch I never landed. I think we should fix it > by creating a different syntax for incorporating a single character in > makeString.
Good point! I was just talking to Sam yesterday about HexInt(...) helpers too. That's kinda the same as RawPointer(...). I filed a bug to do this:
https://bugs.webkit.org/show_bug.cgi?id=180753
I'll try to get to it before end of year :-)
Charlie Turner
Comment 9
2018-12-30 08:44:19 PST
(In reply to JF Bastien from
comment #2
)
> Comment on
attachment 329158
[details]
> patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=329158&action=review
> > > Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:84 > > + EXPECT_EQ("hello * world", makeString("hello ", static_cast<unsigned short>(42) , " world")); // Treated as a character. > > Note this! It's weird, but already pre-existed my patch! I'm just testing it > now, and was surprised but I guess it makes sense given our odd 16-bit > character types...
In WPE (and Windows given
https://bugs.webkit.org/show_bug.cgi?id=187712
) this seems like a dodgy test. UChar == char16_t on my machine, and apparently wchar_t on Windows. I think we're testing undefined behaviour here. Would you object to me removing this test expectation?
https://bugs.webkit.org/show_bug.cgi?id=187712
explains why the template deduction breaks down in these alternative cases, it would be nice to avoid adding more platform ifdefs in the testsuites for the alternative platforms. TIA!
Charlie Turner
Comment 10
2019-01-03 03:44:16 PST
Proposed fix for this issue:
https://bugs.webkit.org/show_bug.cgi?id=193101
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug