WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 162929
[Bindings] Declare dictionary / enumeration template specializations in the header
https://bugs.webkit.org/show_bug.cgi?id=162929
Summary
[Bindings] Declare dictionary / enumeration template specializations in the h...
Chris Dumez
Reported
2016-10-04 12:15:30 PDT
Move convertDictionary<>() template specializations to the header in order to: - Allow them to be used from custom bindings code. - Prepare for moving dictionaries to their own IDL files (
Bug 162912
).
Attachments
Patch
(103.09 KB, patch)
2016-10-04 14:23 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Patch
(103.16 KB, patch)
2016-10-04 14:37 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Patch
(94.59 KB, patch)
2016-10-04 16:27 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Patch
(30.60 KB, patch)
2016-10-04 22:04 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2016-10-04 14:23:06 PDT
Created
attachment 290643
[details]
Patch
Chris Dumez
Comment 2
2016-10-04 14:37:42 PDT
Created
attachment 290645
[details]
Patch
Sam Weinig
Comment 3
2016-10-04 15:37:38 PDT
Do the implementations really have to go in the header? Can't we just forward declare what we want to call?
Chris Dumez
Comment 4
2016-10-04 15:45:27 PDT
(In reply to
comment #3
)
> Do the implementations really have to go in the header? Can't we just > forward declare what we want to call?
Your comment only applies to jsStringWithCache() right? All other functions are templated so I believe they will need to be defined in the header if we want them to be callable from other compilation units. I do think we can move the definition of jsStringWithCache() to the cpp though and only keep its declaration in the header.
Chris Dumez
Comment 5
2016-10-04 15:47:05 PDT
(In reply to
comment #4
)
> (In reply to
comment #3
) > > Do the implementations really have to go in the header? Can't we just > > forward declare what we want to call? > > Your comment only applies to jsStringWithCache() right? All other functions > are templated so I believe they will need to be defined in the header if we > want them to be callable from other compilation units. > > I do think we can move the definition of jsStringWithCache() to the cpp > though and only keep its declaration in the header.
Although I don't know about the performance impact of doing so given that the function was likely being inlined.
Chris Dumez
Comment 6
2016-10-04 16:27:13 PDT
Created
attachment 290665
[details]
Patch
Chris Dumez
Comment 7
2016-10-04 16:31:00 PDT
I have moved jsStringWithCache() implementation back to the cpp. I haven't tried instantiating the template functions in the header and moving the template specializations to the cpp yet.
Chris Dumez
Comment 8
2016-10-04 16:34:18 PDT
(In reply to
comment #7
)
> I haven't > tried instantiating the template functions in the header and moving the > template specializations to the cpp yet.
The thing is that I worry it will lead to linking errors when actually calling the specialization from another compilation unit (which we do not do yet so I won't notice) or about getting weird compilation trouble on Windows. When I have tried tricks like this in the past, it usually hasn't gone well :/ Do you mind if we try doing so in a follow-up, once we actually start sharing dictionaries (i.e. after
Bug 161932
is fixed)?
Chris Dumez
Comment 9
2016-10-04 20:54:26 PDT
(In reply to
comment #8
)
> (In reply to
comment #7
) > > I haven't > > tried instantiating the template functions in the header and moving the > > template specializations to the cpp yet. > > The thing is that I worry it will lead to linking errors when actually > calling the specialization from another compilation unit (which we do not do > yet so I won't notice) or about getting weird compilation trouble on Windows. > > When I have tried tricks like this in the past, it usually hasn't gone well > :/ > > Do you mind if we try doing so in a follow-up, once we actually start > sharing dictionaries (i.e. after
Bug 161932
is fixed)?
Oh, it looks like it is easier than I thought. I'll try and do it in this patch.
Chris Dumez
Comment 10
2016-10-04 22:04:13 PDT
Created
attachment 290688
[details]
Patch
Chris Dumez
Comment 11
2016-10-05 09:11:50 PDT
Comment on
attachment 290688
[details]
Patch Clearing flags on attachment: 290688 Committed
r206812
: <
http://trac.webkit.org/changeset/206812
>
Chris Dumez
Comment 12
2016-10-05 09:11:56 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