Summary: | Don't inline ~ListRefPtr() to workaround winscw compiler forward declaration limitation. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Yongjun Zhang <yongjun.zhang> | ||||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | commit-queue, darin, koshuin | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | S60 Emulator | ||||||||||
OS: | S60 3rd edition | ||||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 27065, 29738 | ||||||||||
Attachments: |
|
Description
Yongjun Zhang
2009-09-11 09:11:18 PDT
Created attachment 39449 [details]
Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other compilers.
(In reply to comment #1) > Created an attachment (id=39449) [details] > Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other > compilers. This can be solved by not inlining the corresponding constructor and assignement operator from refptr.h ? (In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=39449) [details] [details] > > Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other > > compilers. > This can be solved by not inlining the corresponding constructor and > assignement operator from refptr.h ? No, this is for ListRefPtr which is a different templated class than RefPtr. Comment on attachment 39449 [details]
Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other compilers.
Can you help us understand this limitation more? Have you filed a bug with the winscw folks? Do they have a public bug tracker?
(In reply to comment #4) > (From update of attachment 39449 [details]) > Can you help us understand this limitation more? Have you filed a bug with the > winscw folks? Do they have a public bug tracker? Sorry I didn't explain it in detail in error description. ~ListRefPtr() has the following line: RefPtr<T> reaper = this->release(); which calls the ctr RefPtr<T>::RefPtr(T*), where ref() is called. Winscw compiler tries to resolve T::ref() when ~ListRefPtr() is inlined, and it fails if class T is not defined before that. I filed a bug to winscw team: https://xdabug001.ext.nokia.com/bugzilla/show_bug.cgi?id=9812 for similar issue in https://bugs.webkit.org/show_bug.cgi?id=28054. Janne, you are right. If we don't inline the ctor and assignment operator in RefPtr.h, this problem could be resolved. There is another patch trying to address the same issue for KeyframeList and AnimationBase (https://bugs.webkit.org/show_bug.cgi?id=29204). And it could be also resolved by removing inline for PassRefPtr's ctor and assignment operator. Therefore, if we change PassRefPtr & RefPtr's ctor and assignement operator, we can avoid making changes in other places. Eric, do you think it is a better approach? Comment on attachment 39449 [details]
Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other compilers.
Maybe I don't understand C++ well enough, but I don't understand how you can have non-inline template code in a header. I don't see what the "inline" keyword would do here, the destructor will always be inlined, no?
Also, this needs a comment in the code and a link to the winscw bug.
What is being forward declared here that winscw can't understand?
(In reply to comment #6) > (From update of attachment 39449 [details]) > Maybe I don't understand C++ well enough, but I don't understand how you can > have non-inline template code in a header. You're right to doubt your C++ knowledge here, Eric. Template code goes in headers; whether it's marked inline or not is not important. It's not correct to have a non-template function in a header unless it's marked inline, but that does not apply to function templates. (In reply to comment #6) Thanks a lot, Eric. > Also, this needs a comment in the code and a link to the winscw bug. > What is being forward declared here that winscw can't understand? (In reply to comment #6) Thanks a lot, Eric. > Also, this needs a comment in the code and a link to the winscw bug. I will modify the patch as suggested. > What is being forward declared here that winscw can't understand? Class FontFamily (in WebCore/platform/graphics) has member " ListRefPtr<SharedFontFamily> m_next". SharedFontFamily is forward declared but winscw compiler complains it is not enough to resolve SharedFontFamily::ref(), when ~ListRefPtr is inlined in the implicit default dtor of FontFamily (which is inlined too). To summerize how this happens: 1. ~FontFamily() is inlined, the compiler tries to resolve ~ListRefPtr() from inside. 2. ~ListRefPtr() has line "RefPtr<T> reaper = this->release();", which calls the ctr RefPtr<T>::RefPtr(T*), where ref() is called. Winscw compiler tries to resolve T::ref() when ~ListRefPtr() is inlined, and it fails if class T is not defined before that. Created attachment 40235 [details]
modify patch to include Eric's comments.
add link to winscw compiler bug in ChangeLog, to remind us revert this change when the bug is fixed.
Created attachment 40242 [details]
modify patch to include Eric's comments.
document the winscw compiler bug in ChangeLog and the changed source code.
Comment on attachment 40242 [details] modify patch to include Eric's comments. Clearing flags on attachment: 40242 Committed r48988: <http://trac.webkit.org/changeset/48988> All reviewed patches have been landed. Closing bug. |