Also clean up the code a bit.
Created attachment 378129 [details] proposed patch.
<rdar://problem/55087505>
<rdar://problem/55087515>
Comment on attachment 378129 [details] proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=378129&action=review r=me > Source/bmalloc/ChangeLog:17 > + 5. Change LLInt's loadCagedJSValue() to skip the caging if Gigacage is not enabled > + in the build. This allows us to remove the unneeded stubs in WTF Gigacage.h. nit: some part of this belongs in the JSC changelog. > Source/bmalloc/bmalloc/Gigacage.h:50 > + NumberOfKinds // This should always be at the end of this list. this comment is implied by the name of the enum value > Source/bmalloc/bmalloc/Gigacage.h:61 > + break; // Invalid: go to BCRASH(); no need for this comment
Thanks for the review. (In reply to Saam Barati from comment #4) > > Source/bmalloc/ChangeLog:17 > > + 5. Change LLInt's loadCagedJSValue() to skip the caging if Gigacage is not enabled > > + in the build. This allows us to remove the unneeded stubs in WTF Gigacage.h. > > nit: some part of this belongs in the JSC changelog. Fixed. > > > Source/bmalloc/bmalloc/Gigacage.h:50 > > + NumberOfKinds // This should always be at the end of this list. > > this comment is implied by the name of the enum value Fixed. > > Source/bmalloc/bmalloc/Gigacage.h:61 > > + break; // Invalid: go to BCRASH(); > > no need for this comment Fixed.
Created attachment 378133 [details] patch for landing.
The jsc EWS is red purportedly due to a build failure. However, that failure can only manifest if the bot is picking up an outdated Gigacage.h. Obviously, the JSC lib built correctly for all the other bots. So the jsc EWS failure is bogus.
Landed in r249556: <http://trac.webkit.org/r249556>.