Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
crashes on concurrent setModel() and getDispatchForURL() in
JunitTest_chart2_unoapi:
Thread 13:
7 in (anonymous namespace)::Frame::isActionLocked (this=0x2b66c0e4a090) at /home/tinderbox/master/framework/source/services/frame.cxx:2596
8 in (anonymous namespace)::Frame::close (this=0x2b66c0e4a090, bDeliverOwnership=0 '\000') at /home/tinderbox/master/framework/source/services/frame.cxx:1772
9 in chart::ChartController::notifyClosing (this=0x2b668ae41058, rSource=...) at /home/tinderbox/master/chart2/source/controller/main/ChartController.cxx:872
10 in apphelper::CloseableLifeTimeManager::impl_doClose (this=0x2b669a0b1d08) at /home/tinderbox/master/chart2/source/tools/LifeTime.cxx:360
11 in apphelper::CloseableLifeTimeManager::g_close_endTryClose_doClose (this=0x2b669a0b1d08) at /home/tinderbox/master/chart2/source/tools/LifeTime.cxx:311
12 in chart::ChartModel::close (this=0x2b669a0b1c28, bDeliverOwnership=1 '\001') at /home/tinderbox/master/chart2/source/model/main/ChartModel.cxx:659
Thread 1:
4 in std::__debug::map<rtl::OUString, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatch>, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatch> > > >::find (this=0x2b668ae41248, __x=...) at /usr/include/c++/4.8.3/debug/map.h:382
No locals.
5 in chart::CommandDispatchContainer::getDispatchForURL (this=0x2b668ae41248, rURL=...) at /home/tinderbox/master/chart2/source/controller/main/CommandDispatchContainer.cxx:80
6 in chart::ChartController::queryDispatch (this=0x2b668ae41058, rURL=..., rTargetFrameName=...) at /home/tinderbox/master/chart2/source/controller/main/ChartController.cxx:1003
No locals.
7 in framework::DispatchProvider::implts_queryFrameDispatch (this=0x2b66a3fd21e8, xFrame=..., aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/dispatchprovider.cxx:374
8 in framework::DispatchProvider::queryDispatch (this=0x2b66a3fd21e8, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/dispatchprovider.cxx:111
9 in framework::InterceptionHelper::queryDispatch (this=0x2b668a61bc08, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/interceptionhelper.cxx:78
10 in (anonymous namespace)::Frame::queryDispatch (this=0x2b66c0e4a090, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/services/frame.cxx:2227
11 in svt::ToolboxController::bindListener (this=0x2b66c0f72740) at /home/tinderbox/master/svtools/source/uno/toolboxcontroller.cxx:529
12 in svt::ToolboxController::update (this=0x2b66c0f72740) at /home/tinderbox/master/svtools/source/uno/toolboxcontroller.cxx:232
13 in framework::ToolBarManager::UpdateControllers (this=0x2b669a0a1728) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:440
14 in framework::ToolBarManager::AsyncUpdateControllersHdl (this=0x2b669a0a1728) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:2110
15 in framework::ToolBarManager::LinkStubAsyncUpdateControllersHdl (pThis=0x2b669a0a1728, pCaller=0x2b669a0a1890) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:2097
16 in Link::Call (this=0x2b669a0a18b0, pCaller=0x2b669a0a1890) at /home/tinderbox/master/include/tools/link.hxx:139
17 in Timer::Timeout (this=0x2b669a0a1890) at /home/tinderbox/master/vcl/source/app/timer.cxx:276
Change-Id: I17ef63db8f7c288460e00031e8e8a5c3e4d086b3
and make the two categories of constants non-overlapping, we
really don't need to risk confusion in order to save 6 bits in
a data structure like this.
Change-Id: I2251195d8e45ed04e2a89e47ae9c3e52cf0475c0
they are largely unnecessary these days, since our OUString infrastructure
gained optimised handling for static char constants.
Change-Id: I07f73484f82d0582252cb4324d4107c998432c37
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
...to gain further confidence in the claim "that none of the existing
code tries to uses combinations of these enum values"
(d92602c5b13d0a60439d86c5a033d124178726ca "more fixes for SfxItemState")
Change-Id: I987922d945e8738e38adfde83b869adf3ff35b13
Reviewed-on: https://gerrit.libreoffice.org/11384
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Regression to master.
In long term it would be better to define ChartWindow as an
OpenGL window and not creating a new window inside the chart
window, becasue otherwise all events which was handled well
by the chart window will be broken (catched by the OpenGL
window so no effect on ChartWindow (defining the behavior of
charts in general) or catched by the ChartWindow and so no
effect on the OpenGLWindow (like invalidating in this case).
Change-Id: I234f469f70914e01f030c8edae9cb5aacea112bf
Problem after ChartWindow was disabled and enabled
again, OpenGL content was lost.
Two things:
-After setting a new OpenGLWindow the corresponding
IRenderer must be set (x3DWindowProvider->update)
-InitOpenGL() call should not depend on DummyChart, but on
OpenGLWindow (OpenGLContext).
Change-Id: If74e1945de9973d3921ceea1ca6fef39311add7a
...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I6d8b3709d6d55bd6958d38f262141c43779dfdcc
Problem after ChartWindow was disabled and enabled
again, OpenGL content was lost.
Two things:
-After setting a new OpenGLWindow the corresponding
IRenderer must be set (x3DWindowProvider->update)
-InitOpenGL() call should not depend on DummyChart, but on
OpenGLWindow (OpenGLContext).
Change-Id: If74e1945de9973d3921ceea1ca6fef39311add7a
