Bug 171405

Summary: Add StringView::toExistingAtomicString()
Product: WebKit Reporter: Daniel Bates <dbates>
Component: Web Template FrameworkAssignee: Daniel Bates <dbates>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, buildbot, cdumez, cmarcelo, darin, kling, sam, ysuzuki
Priority: P2    
Version: WebKit Local Build   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 170925    
Attachments:
Description Flags
Patch
none
Patch none

Daniel Bates
Reported 2017-04-27 16:33:45 PDT
As suggested by Darin Adler in bug #170925, comment 7 and echoed by Sam Weinig in bug #170925, comment 14, we should add the convenience function StringView::toExistingAtomicString() to return an existing AtomicStringImpl for the string represented by the StringView if one exists. Returning an existing atomic string is more efficient than creating a new one using StringView::toAtomicString().
Attachments
Patch (4.89 KB, patch)
2017-04-27 16:55 PDT, Daniel Bates 		no flags
DetailsFormatted DiffDiff
Patch (4.87 KB, patch)
2017-04-27 16:56 PDT, Daniel Bates 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Daniel Bates
Comment 1 2017-04-27 16:55:14 PDT
Created attachment 308479 [details] Patch Is there a reason for the AtomicStringImpl::lookUp() functions taking a non-const pointer to a LChar/UChar? I mean, AtomicStringImpl does not mutate the LChar/UChar* buffer passed when performing a lookup. I am unclear how we came to the decision to have these functions (formerley named AtomicString::find()) take non-const pointers to buffers other than to match the non-constness of the buffer passed by the callers that motiviated the addition of these lookup functions in <http://trac.webkit.org/changeset/168256> (bug #132548). We seemed to explicitly avoid making these lookup functions take a const pointer to a buffer and added AtomicString::findInternal() when we later moved and renamed AtomicString::find() to AtomicStringImpl::lookUp() in <https://trac.webkit.org/changeset/182915> (bug #43404). Why?
Daniel Bates
Comment 2 2017-04-27 16:56:39 PDT
Created attachment 308480 [details] Patch
Andreas Kling
Comment 3 2017-04-28 06:28:19 PDT
Comment on attachment 308480 [details] Patch r=me :)
Daniel Bates
Comment 4 2017-04-28 14:22:23 PDT
Comment on attachment 308480 [details] Patch Clearing flags on attachment: 308480 Committed r215947: <http://trac.webkit.org/changeset/215947>
Daniel Bates
Comment 5 2017-04-28 14:22:25 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.