RESOLVED FIXED 75296
JSString should not have JS_EXPORTCLASS annotation
https://bugs.webkit.org/show_bug.cgi?id=75296
Summary JSString should not have JS_EXPORTCLASS annotation
Hajime Morrita
Reported 2011-12-28 00:54:08 PST
JSString is annotated JS_EXPORTCLASS but we should remove it because it's no longer a part of public (exported) API. With this annotation, turning export macros on will result extra symbol exposure.
Attachments
Patch (1.21 KB, patch)
2011-12-28 01:02 PST, Hajime Morrita
no flags
An attempt to fix windows build break (2.55 KB, patch)
2012-01-06 00:51 PST, Hajime Morrita
no flags
Hajime Morrita
Comment 1 2011-12-28 01:02:44 PST
Alexey Proskuryakov
Comment 2 2011-12-30 12:28:52 PST
JSString is used in WebCore (see e.g. DOMWrapperWorld.h). Why does it matter that it's not part of a public API?
Kevin Ollivier
Comment 3 2012-01-01 18:58:05 PST
(In reply to comment #2) > JSString is used in WebCore (see e.g. DOMWrapperWorld.h). Why does it matter that it's not part of a public API? It is WebKit policy that APIs that are not public should export only the methods needed by WebCore, etc., to discourage third party developers from coding against those APIs. Hajime's patch is not removing the JSString exports entirely, just decreasing what is exported to only what is needed.
Kevin Ollivier
Comment 4 2012-01-04 17:32:30 PST
Comment on attachment 120640 [details] Patch It looks like Windows needs the class declaration exported in order to provide access to JSString's vtable. I'd have to double-check, but I think the reason this patch works for other platforms is that gcc lets you add the class's vtable to the symbol exports file, but Windows does not. This is probably why we have JS_EXPORTCLASS and JS_EXPORTDATA macros even though we're using symbol export files.
Kevin Ollivier
Comment 5 2012-01-04 17:34:29 PST
(In reply to comment #4) > (From update of attachment 120640 [details]) > It looks like Windows needs the class declaration exported in order to provide access to JSString's vtable. I'd have to double-check, but I think the reason this patch works for other platforms is that gcc lets you add the class's vtable to the symbol exports file, but Windows does not. This is probably why we have JS_EXPORTCLASS and JS_EXPORTDATA macros even though we're using symbol export files. Sorry, by "Windows" I meant the Apple Windows port's compiler, that is, Visual C++.
Hajime Morrita
Comment 6 2012-01-04 23:11:19 PST
Oliver, thanks for your explanation and investigation. > It looks like Windows needs the class declaration exported in order to provide access to JSString's vtable. I'd have to double-check, but I think the reason this patch works for other platforms is that gcc lets you add the class's vtable to the symbol exports file, but Windows does not. This is probably why we have JS_EXPORTCLASS and JS_EXPORTDATA macros even though we're using symbol export files Interesting. And I didn't know that Apple Windows port already relies on the macro. I'll try another patch to examine my understanding. If if doesn't work, I'll close this bug as invalid.
Hajime Morrita
Comment 7 2012-01-06 00:51:03 PST
Created attachment 121408 [details] An attempt to fix windows build break
WebKit Review Bot
Comment 8 2012-01-06 16:55:12 PST
Comment on attachment 121408 [details] An attempt to fix windows build break Clearing flags on attachment: 121408 Committed r104359: <http://trac.webkit.org/changeset/104359>
WebKit Review Bot
Comment 9 2012-01-06 16:55:17 PST
All reviewed patches have been landed. Closing bug.
Adam Roben (:aroben)
Comment 10 2012-01-11 14:05:45 PST
FYI, this caused bug 76101
Hajime Morrita
Comment 11 2012-01-11 23:01:34 PST
(In reply to comment #10) > FYI, this caused bug 76101 Oops. Thanks for fixing that.
Note You need to log in before you can comment on or make changes to this bug.