Timeline
Dec 28, 2015:
- 9:15 PM Changeset in webkit [194434] by
-
- 3 edits in trunk/Source/WebCore
Fix Windows build, ostensibly after r194424.
- CMakeLists.txt:
- PlatformWin.cmake:
ml.exe was given too many unneeded parameters (/Idir1 /Idir2 etc.), and it was failing sometimes with long directories.
Instead of compiling makesafeseh.asm as a normal source file, we now put only the parameters that are needed to assemble
the object file, then link with the object file.
- 4:50 PM Changeset in webkit [194433] by
-
- 5 edits2 moves in trunk/Source/WebCore
Modern IDB: Rename IDBServerOperation to ServerOpenDBRequest.
https://bugs.webkit.org/show_bug.cgi?id=152577
Reviewed by Andy Estes.
No new tests (Refactor, no behavior change)
- CMakeLists.txt:
- WebCore.xcodeproj/project.pbxproj:
- Modules/indexeddb/server/ServerOpenDBRequest.cpp: Renamed from Source/WebCore/Modules/indexeddb/server/IDBServerOperation.cpp.
(WebCore::IDBServer::ServerOpenDBRequest::create):
(WebCore::IDBServer::ServerOpenDBRequest::ServerOpenDBRequest):
(WebCore::IDBServer::ServerOpenDBRequest::isOpenRequest):
(WebCore::IDBServer::ServerOpenDBRequest::isDeleteRequest):
(WebCore::IDBServer::ServerOpenDBRequest::notifyDeleteRequestBlocked):
(WebCore::IDBServer::ServerOpenDBRequest::notifyDidDeleteDatabase):
- Modules/indexeddb/server/ServerOpenDBRequest.h: Renamed from Source/WebCore/Modules/indexeddb/server/IDBServerOperation.h.
(WebCore::IDBServer::ServerOpenDBRequest::connection):
(WebCore::IDBServer::ServerOpenDBRequest::requestData):
(WebCore::IDBServer::ServerOpenDBRequest::hasNotifiedDeleteRequestBlocked):
- Modules/indexeddb/server/UniqueIDBDatabase.cpp:
(WebCore::IDBServer::UniqueIDBDatabase::openDatabaseConnection):
(WebCore::IDBServer::UniqueIDBDatabase::performCurrentOpenOperation):
(WebCore::IDBServer::UniqueIDBDatabase::performCurrentDeleteOperation):
(WebCore::IDBServer::UniqueIDBDatabase::handleDatabaseOperations):
(WebCore::IDBServer::UniqueIDBDatabase::handleCurrentOperation):
(WebCore::IDBServer::UniqueIDBDatabase::handleDelete):
(WebCore::IDBServer::UniqueIDBDatabase::startVersionChangeTransaction):
(WebCore::IDBServer::UniqueIDBDatabase::notifyConnectionsOfVersionChangeForUpgrade):
(WebCore::IDBServer::UniqueIDBDatabase::operationAndTransactionTimerFired):
- Modules/indexeddb/server/UniqueIDBDatabase.h:
- 3:18 PM Changeset in webkit [194432] by
-
- 2 edits in trunk/Tools
Unreviewed, move Sebastian Dröge to committers list
He accidentally added himself to the reviewers list because the file is confusing.
- Scripts/webkitpy/common/config/contributors.json:
- 2:46 PM Changeset in webkit [194431] by
-
- 4 edits in trunk/Source/JavaScriptCore
FTL B3 should know that used registers are not the same thing as used registers. Rename the
latter to unavailable registers to avoid future confusion.
https://bugs.webkit.org/show_bug.cgi?id=152572
Reviewed by Saam Barati.
Prior to this change, we used the term "used registers" in two different senses:
- The set of registers that are live at some point in the current compilation unit. A register is live at some point if it is read after that point on some path through that point.
- The set of registers that are not available for scratch register use at some point. A register may not be available if it is live or if it is a callee-save register but it is not being saved by the current compilation.
In the old FTL LLVM code, we had some translations from the first sense into the second
sense. We forgot to do those in FTL B3, and so we get crashes, for example in V8/splay. That
benchmark highlighted this issue because it fired some lazy slow paths, and then used an
unsaved callee-save for scratch.
Curiously, we could merge these two definitions by observing that, in some sense, an unsaved
callee save is live at every point in a compilation in the sense that it may contain a value
that will be read when the compilation returns. That's pretty cool, but it feels strange to
me. This isn't how we would normally define liveness of registers. It's not how the
Air::TmpLiveness analysis would do it for any of its other clients.
So, this changes B3 to have two different concepts:
- Used registers. These are the registers that are live.
- Unavailable registers. These are the registers that are not available for scratch. It's always a superset of used registers.
This also changes FTLLower to use unavailableRegisters() pretty much everywhere that it
previously used usedRegisters().
This makes it possible to run V8/splay.
- b3/B3StackmapGenerationParams.cpp:
(JSC::B3::StackmapGenerationParams::usedRegisters):
(JSC::B3::StackmapGenerationParams::unavailableRegisters):
(JSC::B3::StackmapGenerationParams::proc):
- b3/B3StackmapGenerationParams.h:
- ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
(JSC::FTL::DFG::LowerDFGToLLVM::getById):
(JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
- 9:22 AM Changeset in webkit [194430] by
-
- 2 edits in trunk/Source/ThirdParty/ANGLE
[ANGLE][EFL][GTK] Remove 'template<class> class std::auto_ptr is deprecated' compile warning
https://bugs.webkit.org/show_bug.cgi?id=152567
Reviewed by Alex Christensen.
Because auto_ptr is deprecated as of C++11, we should use unique_ptr instead.
- src/compiler/preprocessor/MacroExpander.h:
- 9:21 AM Changeset in webkit [194429] by
-
- 2 edits in trunk/Source/WebCore
[CMake][EFL] Fix build breaks when enabling GAMEPAD
https://bugs.webkit.org/show_bug.cgi?id=152573
Reviewed by Alex Christensen.
When enabling GAMEPAD feature on EFL and GTK, there are build breaks.
Fixed all.
- CMakeLists.txt:
- 8:26 AM Changeset in webkit [194428] by
-
- 41 edits in trunk/Source
Stop moving local objects in return statements
https://bugs.webkit.org/show_bug.cgi?id=152557
Reviewed by Brady Eidson.
Source/JavaScriptCore:
Calling std::move() on a local object in a return statement prevents the compiler from applying the return value optimization.
Clang can warn about these mistakes with -Wpessimizing-move, although only when std::move() is called directly.
I found these issues by temporarily replacing WTF::move with std::move and recompiling.
- inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::buildInspectorArray):
- inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::buildInspectorObject):
- jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::snapshot):
- runtime/TypeSet.cpp:
(JSC::TypeSet::allStructureRepresentations):
(JSC::StructureShape::inspectorRepresentation):
Source/WebCore:
Calling std::move() on a local object in a return statement prevents the compiler from applying the return value optimization.
Clang can warn about these mistakes with -Wpessimizing-move, although only when std::move() is called directly.
I found these issues by temporarily replacing WTF::move with std::move and recompiling.
- Modules/indexeddb/IDBDatabaseIdentifier.cpp:
(WebCore::IDBDatabaseIdentifier::isolatedCopy):
- Modules/indexeddb/IDBKeyData.cpp:
(WebCore::IDBKeyData::deletedValue):
- Modules/indexeddb/client/IDBDatabaseImpl.cpp:
(WebCore::IDBClient::IDBDatabase::objectStoreNames):
(WebCore::IDBClient::IDBDatabase::startVersionChangeTransaction):
- Modules/indexeddb/client/IDBTransactionImpl.cpp:
(WebCore::IDBClient::IDBTransaction::createObjectStore):
(WebCore::IDBClient::IDBTransaction::createIndex):
(WebCore::IDBClient::IDBTransaction::doRequestOpenCursor):
(WebCore::IDBClient::IDBTransaction::requestGetRecord):
(WebCore::IDBClient::IDBTransaction::requestIndexRecord):
(WebCore::IDBClient::IDBTransaction::requestClearObjectStore):
(WebCore::IDBClient::IDBTransaction::requestPutOrAdd):
- Modules/indexeddb/server/UniqueIDBDatabase.cpp:
(WebCore::IDBServer::UniqueIDBDatabase::takeNextRunnableTransaction):
- Modules/indexeddb/shared/IDBDatabaseInfo.cpp:
(WebCore::IDBDatabaseInfo::isolatedCopy):
(WebCore::IDBDatabaseInfo::objectStoreNames):
- Modules/indexeddb/shared/IDBResultData.cpp:
(WebCore::IDBResultData::error):
(WebCore::IDBResultData::openDatabaseSuccess):
(WebCore::IDBResultData::openDatabaseUpgradeNeeded):
- Modules/indexeddb/shared/IDBTransactionInfo.cpp:
(WebCore::IDBTransactionInfo::versionChange):
(WebCore::IDBTransactionInfo::isolatedCopy):
- Modules/indexeddb/shared/InProcessIDBServer.cpp:
(WebCore::InProcessIDBServer::create):
- Modules/webaudio/OfflineAudioContext.cpp:
(WebCore::OfflineAudioContext::create):
- Modules/webdatabase/DatabaseTracker.cpp:
(WebCore::DatabaseTracker::originLockFor):
- Modules/websockets/WebSocket.cpp:
(WebCore::WebSocket::create):
- css/CSSPrimitiveValue.cpp:
(WebCore::CSSPrimitiveValue::formatNumberValue):
- dom/NodeOrString.cpp:
(WebCore::convertNodesOrStringsIntoNode):
- inspector/InspectorApplicationCacheAgent.cpp:
(WebCore::InspectorApplicationCacheAgent::buildArrayForApplicationCacheResources):
- inspector/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::buildObjectForNode):
(WebCore::InspectorDOMAgent::buildArrayForElementAttributes):
(WebCore::InspectorDOMAgent::buildArrayForContainerChildren):
(WebCore::InspectorDOMAgent::buildObjectForEventListener):
- inspector/InspectorIndexedDBAgent.cpp:
- inspector/InspectorLayerTreeAgent.cpp:
(WebCore::InspectorLayerTreeAgent::buildObjectForLayer):
- inspector/InspectorNetworkAgent.cpp:
(WebCore::buildObjectForHeaders):
(WebCore::buildObjectForResourceRequest):
(WebCore::buildObjectForCachedResource):
- inspector/InspectorOverlay.cpp:
(WebCore::buildArrayForQuad):
(WebCore::buildObjectForFlowRegions):
(WebCore::InspectorOverlay::buildObjectForHighlightedNodes):
- inspector/InspectorPageAgent.cpp:
(WebCore::createXHRTextDecoder):
(WebCore::buildArrayForCookies):
(WebCore::InspectorPageAgent::buildObjectForFrame):
- inspector/InspectorStyleSheet.cpp:
(WebCore::buildMediaObject):
(WebCore::InspectorStyle::buildArrayForComputedStyle):
(WebCore::buildObjectForSelectorHelper):
(WebCore::selectorsFromSource):
(WebCore::InspectorStyleSheet::buildObjectForSelectorList):
(WebCore::InspectorStyleSheet::buildObjectForStyle):
(WebCore::InspectorStyleSheet::buildArrayForRuleList):
- inspector/InspectorTimelineAgent.cpp:
(WebCore::InspectorTimelineAgent::stopFromConsole):
- inspector/TimelineRecordFactory.cpp:
(WebCore::TimelineRecordFactory::createGenericRecord):
(WebCore::TimelineRecordFactory::createFunctionCallData):
(WebCore::TimelineRecordFactory::createConsoleProfileData):
(WebCore::TimelineRecordFactory::createProbeSampleData):
(WebCore::TimelineRecordFactory::createEventDispatchData):
(WebCore::TimelineRecordFactory::createGenericTimerData):
(WebCore::TimelineRecordFactory::createTimerInstallData):
(WebCore::TimelineRecordFactory::createEvaluateScriptData):
(WebCore::TimelineRecordFactory::createTimeStampData):
(WebCore::TimelineRecordFactory::createAnimationFrameData):
(WebCore::createQuad):
(WebCore::TimelineRecordFactory::createPaintData):
(WebCore::buildInspectorObject):
- loader/FrameLoader.cpp:
(WebCore::createWindow):
- loader/NavigationAction.cpp:
(WebCore::NavigationAction::copyWithShouldOpenExternalURLsPolicy):
- page/DOMWindow.cpp:
(WebCore::DOMWindow::createWindow):
- platform/network/ios/QuickLook.mm:
(WebCore::QuickLookHandle::create):
- testing/Internals.cpp:
(WebCore::Internals::openDummyInspectorFrontend):
- workers/WorkerScriptLoader.cpp:
(WebCore::WorkerScriptLoader::createResourceRequest):
- xml/XPathExpression.cpp:
(WebCore::XPathExpression::evaluate):
Source/WebKit2:
Calling std::move() on a local object in a return statement prevents the compiler from applying the return value optimization.
Clang can warn about these mistakes with -Wpessimizing-move, although only when std::move() is called directly.
I found these issues by temporarily replacing WTF::move with std::move and recompiling.
- UIProcess/WebPageProxy.cpp:
(WebKit::ExceededDatabaseQuotaRecords::createRecord):
Source/WTF:
- wtf/StdLibExtras.h: Added a FIXME about how using WTF::move() prevents several Clang diagnostics from emitting useful warnings.
Dec 27, 2015:
- 7:01 PM Changeset in webkit [194427] by
-
- 2 edits in trunk/Source/WebInspectorUI
Web Inspector: improve pre-filled bugzilla link on Uncaught Exception reporter sheet
https://bugs.webkit.org/show_bug.cgi?id=152402
Reviewed by Joseph Pecoraro.
Include the UA string, inspected page URL, and a template that includes
steps to reproduce and notes. Other common headings (regression, expected,
results, summary) are omitted because they are unlikely to be known when
an uncaught exception occurs, or are obvious ("shouldn't throw exception").
- UserInterface/Debug/UncaughtExceptionReporter.js:
- 2:56 PM Changeset in webkit [194426] by
-
- 3 edits2 adds in trunk
Should never be reached failure in WebCore::RenderElement::clearLayoutRootIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=151590
Reviewed by Simon Fraser.
We should always set the layoutroot when a new subtree layout is requested (and convert it
to a full layout when needed). It ensures that renderers are detached cleanly even when
they are set as layoutroot.
Source/WebCore:
Test: fast/block/assert-when-layout-root-is-not-cleared.html
- page/FrameView.cpp:
(WebCore::FrameView::scheduleRelayoutOfSubtree):
LayoutTests:
- fast/block/assert-when-layout-root-is-not-cleared-expected.txt: Added.
- fast/block/assert-when-layout-root-is-not-cleared.html: Added.
