HandlerInfo and UnlinkedHandlerInfo have common parts, but are not currently expressed as 2 unrelated structs that happen to have near identical fields. We can refactor them to better express their relationship. We can also add some convenience functions to make the code that uses them a little more readable.
Created attachment 253935 [details] the patch.
Comment on attachment 253935 [details] the patch. View in context: https://bugs.webkit.org/attachment.cgi?id=253935&action=review > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:132 > + UnlinkedHandlerInfo info(start, end, range.tryData->target->bind(), range.tryData->targetScopeDepth); No need for cast?
(In reply to comment #2) > Comment on attachment 253935 [details] > the patch. > > View in context: > https://bugs.webkit.org/attachment.cgi?id=253935&action=review > > > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:132 > > + UnlinkedHandlerInfo info(start, end, range.tryData->target->bind(), range.tryData->targetScopeDepth); > > No need for cast? My local builds and the bots seem to agree that we don't need the cast, but it might be resulting in noisy warning on the Windows port. I'll restore them before landing.
Thanks for the review. Landed in r185022: <http://trac.webkit.org/r185022>.
Comment on attachment 253935 [details] the patch. View in context: https://bugs.webkit.org/attachment.cgi?id=253935&action=review > Source/JavaScriptCore/bytecode/HandlerInfo.h:51 > + void initialize(const UnlinkedHandlerInfo& unlinkedInfo, size_t nonLocalScopeDepth, CodeLocationLabel label) Using CodeLocationLabel is incorrect here, because it is defined inside ENABLE(ASSEMBLER) guard. Now !ENABLE(ASSEMBLER) build is broken due to this issue. ( !ENABLE(JIT) && !ENABLE(YARR_JIT) ) Could you check it?
The CodeLocationLabel issue is fixed in https://bugs.webkit.org/show_bug.cgi?id=145515.