WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
157465
[Bindings] Simplify [RequiresExistingAtomicString] IDL extended attribute handling
https://bugs.webkit.org/show_bug.cgi?id=157465
Summary
[Bindings] Simplify [RequiresExistingAtomicString] IDL extended attribute han...
Chris Dumez
Reported
2016-05-08 13:25:43 PDT
Simplify [RequiresExistingAtomicString] IDL extended attribute handling in the bindings generator.
Attachments
Patch
(16.44 KB, patch)
2016-05-08 13:39 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2016-05-08 13:39:37 PDT
Created
attachment 278370
[details]
Patch
Darin Adler
Comment 2
2016-05-08 13:46:49 PDT
Comment on
attachment 278370
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=278370&action=review
> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382 > + return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"};
The parentheses here after "return" are not normal perl coding style. I like it better without. It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString?
Chris Dumez
Comment 3
2016-05-08 13:51:53 PDT
Comment on
attachment 278370
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=278370&action=review
>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382 >> + return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"}; > > The parentheses here after "return" are not normal perl coding style. I like it better without. > > It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString?
1. We use these parentheses in all return statements in this function. Do you want be to drop them all? I am not Perl expert but I personally like the parentheses here as it makes it clear we're returning a tuple. 2. Yes, I have tried without the AtomicString() but it did not build. The compiler complains about it being ambiguous because there are 2 overloads in TreeScope.h: Element* getElementById(const AtomicString&) const; WEBCORE_EXPORT Element* getElementById(const String&) const;
Darin Adler
Comment 4
2016-05-08 14:39:25 PDT
Comment on
attachment 278370
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=278370&action=review
>>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382 >>> + return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"}; >> >> The parentheses here after "return" are not normal perl coding style. I like it better without. >> >> It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString? > > 1. We use these parentheses in all return statements in this function. Do you want be to drop them all? > I am not Perl expert but I personally like the parentheses here as it makes it clear we're returning a tuple. > > 2. Yes, I have tried without the AtomicString() but it did not build. The compiler complains about it being ambiguous because there are 2 overloads in TreeScope.h: > Element* getElementById(const AtomicString&) const; > WEBCORE_EXPORT Element* getElementById(const String&) const;
Oops, need the parentheses. Forgot this was a tuple! I really don’t get why toExistingAtomicString returns RefPtr<AtomicStringImpl> instead of AtomicString, but this code is all right with me.
Chris Dumez
Comment 5
2016-05-08 14:56:14 PDT
Comment on
attachment 278370
[details]
Patch Clearing flags on attachment: 278370 Committed
r200562
: <
http://trac.webkit.org/changeset/200562
>
Chris Dumez
Comment 6
2016-05-08 14:56:19 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.
Top of Page
Format For Printing
XML
Clone This Bug