Bug 29187 – Don't inline ~ListRefPtr() to workaround winscw compiler forward declaration limitation.

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Yongjun Zhang]

ListRefPtr is used in FontFamily to embed SharedFontFamily as it's member.  Winscw compiler complains that SharedFontFamily is not defined.

[Yongjun Zhang]

Created attachment 39449 [details]
Don't inline ~ListRefPtr for winscw compiler, keep it inlined for other compilers.

[Janne Koskinen]

(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 ?

[Yongjun Zhang]

(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.

[Eric Seidel (no email)]

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?

[Yongjun Zhang]

(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?

[Eric Seidel (no email)]

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?

[Darin Adler]

(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.

[Yongjun Zhang]

(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?

[Yongjun Zhang]

(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.

[Yongjun Zhang]

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.

[Yongjun Zhang]

Created attachment 40242 [details]
modify patch to include Eric's comments.


document the winscw compiler bug in ChangeLog and the changed source code.

[WebKit Commit Bot]

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>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.