Summary: | [WHLSL] Parsing and lexing the standard library is slow | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Myles C. Maxfield <mmaxfield> | ||||||||||||||||||
Component: | WebGPU | Assignee: | Robin Morisset <rmorisset> | ||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||
Severity: | Normal | CC: | commit-queue, ews-watchlist, rniwa, ryanhaddad, tsavell, webkit-bug-importer | ||||||||||||||||||
Priority: | P1 | Keywords: | InRadar | ||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=192994 https://bugs.webkit.org/show_bug.cgi?id=198186 https://bugs.webkit.org/show_bug.cgi?id=198357 |
||||||||||||||||||||
Bug Depends on: | 192355 | ||||||||||||||||||||
Bug Blocks: | |||||||||||||||||||||
Attachments: |
|
Description
Myles C. Maxfield
2018-12-19 16:06:39 PST
Created attachment 370292 [details]
WIP
Created attachment 370799 [details]
Patch
Comment on attachment 370799 [details]
Patch
The patch does not apply cleanly for some reason.. I will send it for review again once it is fixed.
Created attachment 370805 [details]
Patch
Properly rebased
Attachment 370805 [details] did not pass style-queue:
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:61: Missing space before ( in switch( [whitespace/parens] [5]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:475: A case label should not be indented, but line up with its switch statement. [whitespace/indent] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:507: A case label should not be indented, but line up with its switch statement. [whitespace/indent] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:681: Missing space before ( in switch( [whitespace/parens] [5]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:930: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:981: Missing space before ( in switch( [whitespace/parens] [5]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1202: Missing space before ( in switch( [whitespace/parens] [5]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1253: An else statement can be removed when the prior "if" concludes with a return, break, continue or goto statement. [readability/control_flow] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1469: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1493: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1567: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1602: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1654: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1709: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1743: This { should be at the end of the previous line [whitespace/braces] [4]
ERROR: Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1777: This { should be at the end of the previous line [whitespace/braces] [4]
Total errors found: 16 in 4 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 370805 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370805&action=review > Source/WebCore/ChangeLog:1767 > +2019-05-28 Robin Morisset <rmorisset@apple.com> Changelogs should go at the top of the file. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h:184 > + m_ringBufferIndex = !m_ringBufferIndex; Nit: this could be made more clear by saying (m_ringBufferIndex + 1) % 2. Maybe one day we'll want to have 3 tokens of lookahead. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h:195 > + return m_ringBuffer[!m_ringBufferIndex]; Ditto > Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h:205 > State state() const We should add a FIXME with a link to a bugzilla bug about removing the last of the backtracking, at which point we can delete these functions. The FIXME could go here or it could go where the backtracking occurs (or both). > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:58 > + auto token = m_lexer.peek(); Can't you just call peek( ) instead of going through the parser? Having fewer funnel points is better. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:87 > + ASSERT(m_mode == Mode::StandardLibrary); Shouldn't this be a parse error, rather than an ASSERT()? We can't stop authors from putting the token "native" in their source. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:365 > + if (m_lexer.peek()->type != Lexer::Token::Type::Identifier || m_lexer.peekFurther()->type == Lexer::Token::Type::FullStop) { Did you mechanically generate these tokens using a tool? Or did you figure it out by looking through the grammar yourself? If we add a new type of token, are we going to have to modify lots of places throughout the parser? > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:382 > + auto greaterThanSign = tryType(Lexer::Token::Type::GreaterThanSign); > + if (greaterThanSign) > + return typeArguments; Should there be a macro for this pattern too? It's used in quite a few places. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:703 > + while (auto next = tryType(Lexer::Token::Type::Qualifier)) { The rare "variable declaration in a while loop condition"! I like it! > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:744 > auto structureElement = backtrackingScope<Expected<AST::StructureElement, Error>>([&]() { 😔 > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:986 > + return parseVertexFragmentFunctionDeclaration(); Nit: VertexOrFragment > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1091 > auto parseRemainder = [&](Variant<AST::VariableDeclarationsStatement, UniqueRef<AST::Expression>>&& initialization) -> Expected<AST::ForLoop, Error> { With the new design, is it possible to get rid of this lambda and put its contents directly into parseForLoop()? > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1335 > + auto origin = peek(); > + if (!origin) > + return Unexpected<Error>(origin.error()); Can be macro-ized? > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1667 > + Vector<UniqueRef<AST::Expression>> callArguments; > + callArguments.append(WTFMove(previous)); > + callArguments.append(WTFMove(*next)); Can we say "callArguments { WTFMove(previous), WTFMove(*next) }"? > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1718 > + Vector<UniqueRef<AST::Expression>> callArguments; > + callArguments.append(WTFMove(previous)); > + callArguments.append(WTFMove(*next)); Ditto > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1752 > + Vector<UniqueRef<AST::Expression>> callArguments; > + callArguments.append(WTFMove(previous)); > + callArguments.append(WTFMove(*next)); Ditto > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1787 > + Vector<UniqueRef<AST::Expression>> callArguments; > + callArguments.append(WTFMove(previous)); > + callArguments.append(WTFMove(*next)); Ditto > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1827 > + if (isEffectful) > + *isEffectful = true; If possible, output values should be part of the return type, not out-params. > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1913 > + return fail("Could not read next token in the callExpression case of parsePossibleSuffix()"_str, TryToPeek::No); Isn't a better error message "the term isn't effectful" or "need a semicolon" or something like that? > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h:123 > + void dump(PrintStream& out) const > + { > + out.print(error); > + } Is this ever called? Maybe it should be behind #ifndef NDEBUG Also, possibly rename to dumpError() Thank you for the review! (In reply to Myles C. Maxfield from comment #7) > Comment on attachment 370805 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=370805&action=review > > > Source/WebCore/ChangeLog:1767 > > +2019-05-28 Robin Morisset <rmorisset@apple.com> > > Changelogs should go at the top of the file. will fix > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h:184 > > + m_ringBufferIndex = !m_ringBufferIndex; > > Nit: this could be made more clear by saying (m_ringBufferIndex + 1) % 2. > Maybe one day we'll want to have 3 tokens of lookahead. will fix. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h:205 > > State state() const > > We should add a FIXME with a link to a bugzilla bug about removing the last > of the backtracking, at which point we can delete these functions. The FIXME > could go here or it could go where the backtracking occurs (or both). Will do. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:58 > > + auto token = m_lexer.peek(); > > Can't you just call peek( ) instead of going through the parser? Having > fewer funnel points is better. I will try to fix it. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:87 > > + ASSERT(m_mode == Mode::StandardLibrary); > > Shouldn't this be a parse error, rather than an ASSERT()? We can't stop > authors from putting the token "native" in their source. Ah, I forgot to open a bug about that. The lexer should only treat native as a special keyword while parsing the standard library. It should be a normal identifier in user code. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:365 > > + if (m_lexer.peek()->type != Lexer::Token::Type::Identifier || m_lexer.peekFurther()->type == Lexer::Token::Type::FullStop) { > > Did you mechanically generate these tokens using a tool? Or did you figure > it out by looking through the grammar yourself? > > If we add a new type of token, are we going to have to modify lots of places > throughout the parser? I figured them out by looking myself.. I agree it is ugly as hell, but supporting some new tool in the build system would be a pain, and most tools have some restriction that could make it harder to extend the language. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:382 > > + auto greaterThanSign = tryType(Lexer::Token::Type::GreaterThanSign); > > + if (greaterThanSign) > > + return typeArguments; > > Should there be a macro for this pattern too? It's used in quite a few > places. maybe, but I have not seen it in that many places, and I don't want to make the code harder to read by using rare macros. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:986 > > + return parseVertexFragmentFunctionDeclaration(); > > Nit: VertexOrFragment Will fix. > > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1091 > > auto parseRemainder = [&](Variant<AST::VariableDeclarationsStatement, UniqueRef<AST::Expression>>&& initialization) -> Expected<AST::ForLoop, Error> { > > With the new design, is it possible to get rid of this lambda and put its > contents directly into parseForLoop()? Sadly not yet because there is still ambiguity between variable declarations and effectfulExpr, which will require a change to the array syntax to fix. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1335 > > + auto origin = peek(); > > + if (!origin) > > + return Unexpected<Error>(origin.error()); > > Can be macro-ized? I will look. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1667 > > + Vector<UniqueRef<AST::Expression>> callArguments; > > + callArguments.append(WTFMove(previous)); > > + callArguments.append(WTFMove(*next)); > > Can we say "callArguments { WTFMove(previous), WTFMove(*next) }"? Will do. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1827 > > + if (isEffectful) > > + *isEffectful = true; > > If possible, output values should be part of the return type, not out-params. The problem is that this is not meaningful out of the parser, so I don't want to put it in the expression ast node. I could make this function return a std::pair<AST::Expression, bool>, but it would make all places that call it (including some that don't care about isEffectful) more complicated. I can do it if you think it really matters, but an out param seemed the simplest way. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp:1913 > > + return fail("Could not read next token in the callExpression case of parsePossibleSuffix()"_str, TryToPeek::No); > > Isn't a better error message "the term isn't effectful" or "need a > semicolon" or something like that? Yeah, this error message is terrible. Will fix. > > Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h:123 > > + void dump(PrintStream& out) const > > + { > > + out.print(error); > > + } > > Is this ever called? Maybe it should be behind #ifndef NDEBUG > > Also, possibly rename to dumpError() It must be called dump(), so it can be called implicitly by dataLog and friends. And I frequently need dataLog while in Release mode. It is not currently called because I removed all the dataLog I had generously sprinkled throughout the parser, but it will be useful if we ever need to debug anything in the parser again. Created attachment 370907 [details]
Patch for landing
Comment on attachment 370907 [details] Patch for landing Rejecting attachment 370907 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'apply-attachment', '--no-update', '--non-interactive', 370907, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Logging in as commit-queue@webkit.org... Fetching: https://bugs.webkit.org/attachment.cgi?id=370907&action=edit Fetching: https://bugs.webkit.org/show_bug.cgi?id=192890&ctype=xml&excludefield=attachmentdata Processing 1 patch from 1 bug. Processing patch 370907 from bug 192890. Fetching: https://bugs.webkit.org/attachment.cgi?id=370907 Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Parsed 4 diffs from patch file(s). patching file Source/WebCore/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h patching file Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp Hunk #1 FAILED at 38. Hunk #19 FAILED at 871. 2 out of 43 hunks FAILED -- saving rejects to file Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp.rej patching file Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output: https://webkit-queues.webkit.org/results/12323670 Created attachment 370913 [details]
Patch for landing
Picking the right patch from the right directory this time.
Comment on attachment 370913 [details] Patch for landing Clearing flags on attachment: 370913 Committed r245883: <https://trac.webkit.org/changeset/245883> All reviewed patches have been landed. Closing bug. The changes in https://trac.webkit.org/changeset/245883/webkit appears to have broken 6 test on WK2: webgpu/whlsl-arbitrary-vertex-attribute-locations.html webgpu/whlsl-dereference-pointer-should-type-check.html webgpu/whlsl-dont-crash-parsing-enum.html webgpu/whlsl-dot-expressions.html webgpu/whlsl-nested-dot-expression-rvalue.html webgpu/whlsl.html I reproduced this by running these test on 245883 which all failed, and on 245882 which all passed. Can this be resolved soon? Results: https://build.webkit.org/results/Apple%20Mojave%20Release%20WK2%20(Tests)/r245884%20(4380)/results.html Reverted r245883 for reason: Caused 6 webgpu/ layout test failures. Committed r245897: <https://trac.webkit.org/changeset/245897> Comment on attachment 370913 [details] Patch for landing Attachment 370913 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/12330696 New failing tests: webgpu/whlsl-dereference-pointer-should-type-check.html webgpu/whlsl-dot-expressions.html webgpu/whlsl-arbitrary-vertex-attribute-locations.html webgpu/whlsl.html webgpu/whlsl-dont-crash-parsing-enum.html webgpu/whlsl-nested-dot-expression-rvalue.html Created attachment 370971 [details]
Archive of layout-test-results from ews105 for mac-highsierra-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
These tests were also failing an assertion on debug bots: https://build.webkit.org/results/Apple%20High%20Sierra%20Debug%20WK2%20(Tests)/r245892%20(7962)/results.html ASSERTION FAILED: !failure ./Modules/webgpu/WHLSL/WHLSLPrepare.cpp(101) : Optional<WebCore::WHLSL::Program> WebCore::WHLSL::prepareShared(WTF::String &) 1 0x39aec8c09 WTFCrash 2 0x38800739b WTFCrashWithInfo(int, char const*, char const*, int) 3 0x389d58ca5 WebCore::WHLSL::prepareShared(WTF::String&) 4 0x389d589d7 WebCore::WHLSL::prepare(WTF::String&, WebCore::WHLSL::RenderPipelineDescriptor&) 5 0x3888c4779 WebCore::trySetWHLSLFunctionsForPipelineDescriptor(char const*, MTLRenderPipelineDescriptor*, WebCore::GPURenderPipelineDescriptor const&, WTF::String, WebCore::GPUDevice const&) 6 0x3888c3496 WebCore::trySetFunctionsForPipelineDescriptor(char const*, MTLRenderPipelineDescriptor*, WebCore::GPURenderPipelineDescriptor const&, WebCore::GPUDevice const&) 7 0x3888bf091 WebCore::tryCreateMtlRenderPipelineState(char const*, WebCore::GPURenderPipelineDescriptor const&, WebCore::GPUDevice const&) 8 0x3888be83b WebCore::GPURenderPipeline::tryCreate(WebCore::GPUDevice const&, WebCore::GPURenderPipelineDescriptor const&) 9 0x38b4b02b4 WebCore::GPUDevice::tryCreateRenderPipeline(WebCore::GPURenderPipelineDescriptor const&) const 10 0x389c6f280 WebCore::WebGPUDevice::createRenderPipeline(WebCore::WebGPURenderPipelineDescriptor const&) const 11 0x3895403c6 WebCore::jsWebGPUDevicePrototypeFunctionCreateRenderPipelineBody(JSC::ExecState*, WebCore::JSWebGPUDevice*, JSC::ThrowScope&) 12 0x389535150 long long WebCore::IDLOperation<WebCore::JSWebGPUDevice>::call<&(WebCore::jsWebGPUDevicePrototypeFunctionCreateRenderPipelineBody(JSC::ExecState*, WebCore::JSWebGPUDevice*, JSC::ThrowScope&)), (WebCore::CastedThisErrorBehavior)0>(JSC::ExecState&, char const*) 13 0x389534e3c WebCore::jsWebGPUDevicePrototypeFunctionCreateRenderPipeline(JSC::ExecState*) 14 0x28b308d316b 15 0x39b3e7781 llint_entry 16 0x39b3e76e2 llint_entry 17 0x39b3e76e2 llint_entry 18 0x39b3e7781 llint_entry 19 0x39b3d42d3 vmEntryToJavaScript 20 0x39c05503e JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) 21 0x39c05566f JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 22 0x39c32f47c JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 23 0x39c32f75b JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 24 0x39c4b7e9d JSC::JSMicrotask::run(JSC::ExecState*) 25 0x389f91f27 WebCore::JSExecState::runTask(JSC::ExecState*, JSC::Microtask&) 26 0x389fa37f0 WebCore::JSMicrotaskCallback::call() 27 0x389fa366d WebCore::JSDOMWindowBase::queueTaskToEventLoop(JSC::JSGlobalObject&, WTF::Ref<JSC::Microtask, WTF::DumbPtrTraits<JSC::Microtask> >&&)::$_1::operator()() 28 0x389fa35c9 WTF::Detail::CallableWrapper<WebCore::JSDOMWindowBase::queueTaskToEventLoop(JSC::JSGlobalObject&, WTF::Ref<JSC::Microtask, WTF::DumbPtrTraits<JSC::Microtask> >&&)::$_1, void>::call() 29 0x388013b3d WTF::Function<void ()>::operator()() const 30 0x38a438cb7 WebCore::ActiveDOMCallbackMicrotask::run() 31 0x38a5eaa6d WebCore::MicrotaskQueue::performMicrotaskCheckpoint() LEAK: 3 WebPageProxy Created attachment 371228 [details]
Patch for landing
Found the problem: when applying some of Myles suggestion, I accidentally used m_lexer.peek() in the definition of Parser::peekFurther, instead of m_lexer.peekFurther()
Comment on attachment 371228 [details] Patch for landing Clearing flags on attachment: 371228 Committed r246052: <https://trac.webkit.org/changeset/246052> All reviewed patches have been landed. Closing bug. The changes in https://trac.webkit.org/changeset/246052/webkit has caused 3 webgpu/ tests to fail: webgpu/whlsl-ensure-proper-variable-lifetime-3.html webgpu/whlsl-ensure-proper-variable-lifetime.html webgpu/whlsl-ensure-proper-variable-lifetime-2.html History: http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=webgpu%2Fwhlsl-ensure-proper-variable-lifetime-3.html%20%20webgpu%2Fwhlsl-ensure-proper-variable-lifetime.html%20%20webgpu%2Fwhlsl-ensure-proper-variable-lifetime-2.html Results: https://build.webkit.org/results/Apple%20Mojave%20Release%20WK2%20(Tests)/r246059%20(4469)/results.html Reverted r246052 for reason: Caused 3 webgpu/ failures. Committed r246108: <https://trac.webkit.org/changeset/246108> Created attachment 371452 [details]
Patch for landing
Found two bugs:
- We were only peeking in the first iteration of the loop in parseSwitchStatement instead of every iteration.
- parsePossibleTernaryConditional was consuming a token it should only peek at.
Fixed both, and now all the tests that were failing pass.
I also removed a bit of dead code, and slightly improved the error message when we fail to parse.
Comment on attachment 371452 [details] Patch for landing Clearing flags on attachment: 371452 Committed r246135: <https://trac.webkit.org/changeset/246135> All reviewed patches have been landed. Closing bug. |