Age | Commit message (Collapse) | Author |
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I07bdc60ecc2d8ff9ad9c109f32b350eb09ac72e5
Reviewed-on: https://gerrit.libreoffice.org/60921
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I1c909f6e1984bd4b09c3b67c19659dc276ac3229
Reviewed-on: https://gerrit.libreoffice.org/60984
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ie14e0aaff07fbbaab834158f4666b819a0ba2dbc
Reviewed-on: https://gerrit.libreoffice.org/60967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I83241bd2ed172594704f4b115b584dc39b234086
Reviewed-on: https://gerrit.libreoffice.org/60959
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iec5e591f51ab13efa4b014b82df213e91eb5b793
Reviewed-on: https://gerrit.libreoffice.org/60949
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Icac79eb1c0c47388f96d37d2921c81fb6c848607
Reviewed-on: https://gerrit.libreoffice.org/60948
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I22ba2c8aec235e34cd7835b8a0a716bf3057db7a
Reviewed-on: https://gerrit.libreoffice.org/60837
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In the OOXML standard the supported data label positions in case of
Column and Bar Chart are Center (ctr), Inside End (inEnd),
Inside Base (inBase) and Outside End (outEnd). So even if the default
value is Above of the date labels placement in LibreOffice,
after the export to OOXML the "DLblPos" will be changed to outEnd.
It is not a problem, but the 0 datapoints value will be appear on the
wrong side of the axis and making itself and the the axis text both
undreadable. This patch will fix it in case of OOXML and ODF format too.
Change-Id: I04d68ee79b560cf144e6290271f2341355a5b089
Reviewed-on: https://gerrit.libreoffice.org/60477
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ifa446647b11fd1f1b0dc6a991b752480545634db
Reviewed-on: https://gerrit.libreoffice.org/60788
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8c3b3c0f6c0cfe133e1ec8eda8c10bbbaee5f010
Reviewed-on: https://gerrit.libreoffice.org/60584
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9df9dd3f2bfaedccb4a02681964544daf39f261e
Reviewed-on: https://gerrit.libreoffice.org/60580
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ice26d1fd2ad97a6959c6916fef428777efea9c2d
Reviewed-on: https://gerrit.libreoffice.org/60500
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I89164a9bc4710d9a90d415c2369c2cde3857c778
Reviewed-on: https://gerrit.libreoffice.org/60552
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that recently started to hit quite often during JunitTest_chart2_unoapi, when
the main thread is painting windows and calls ChartView::createShapes (which
calls impl_deleteCoordinateSystems, which clears m_aVCooSysList) while an URP
thread executes chart::WrappedPropertySet::getPropertyValue and calls
ChartView::getExplicitValuesForAxis (which calls findInCooSysList, which
iterates over m_aVCooSysList), all apparently without locking access to
m_aVCooSysList. (See e.g. the below backtraces from
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/14432/console>, where
both threads operate on chart::ChartView instance 0x2633140.)
I assume this issue has always been there, and has only been made noticeable
with recent 3e62ac3e9ef2f6759d8faca2c012dba51c314ba5 "loplugin:useuniqueptr in
VCoordinateSystem", which changed the implementation of
impl_deleteCoordianteSystems from O(1) swap-and-clear to plain O(n) clear of
m_aVCooSysList, which extends the time span in which the thread executing
findInCooSysList can find an inconsistent m_aVCooSysList (and see in the below
backtrace how much code is apparently executed during the destruction of
m_aVCooSysList's VCartesianCoordinateSystem elements).
And indeed, <https://bz.apache.org/ooo/show_bug.cgi?id=109770>
"ChartView::getExplicitValuesForAxis accessing destroyed VCoordinateSystem"
found apparently the same issue already in 2010, and the swap-and-clear was
introduced as a means to address the race in
590a1a5225623eb922e63b02b62e711d153e9d55 "chart43: #i109770#
ChartView::getExplicitValuesForAxis accessing destroyed VCoordinateSystem". (So
the "//#i109770#" comment should have been removed from
impl_deleteCoordinateSystem already when
3e62ac3e9ef2f6759d8faca2c012dba51c314ba5 dropped the swap; catching up on that
now.)
For a proper fix, there appears to be no constitent existing locking scheme for
ChartView (appart from a few scatter SolarMutexGuards). Lets be bold and see
whether it works to put the whole bodies of (at least, for now) createShapes and
getExpliticValuesForAxis under SolarMutexGuards. (Which means the
SolarMutexGuard in createShapes2D can go, as it is exclusively called from
createShapes.)
> Thread 2 (Thread 0x2ae81cbd2840 (LWP 10147)):
> #0 0x00002ae81dee4f9a in __gnu_debug::_Safe_iterator_base::_M_attach(__gnu_debug::_Safe_sequence_base*, bool) () at /lib64/libstdc++.so.6
> #1 0x00002ae822e0a685 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base(__gnu_debug::_Safe_sequence_base const*, bool) (this=0x7ffedb73c598, __seq=0x2acc2f0, __constant=false) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/safe_base.h:89
> #2 0x00002ae822f75c6a in __gnu_debug::_Safe_iterator<std::__cxx1998::_Deque_iterator<SfxBroadcaster*, SfxBroadcaster*&, SfxBroadcaster**>, std::__debug::deque<SfxBroadcaster*, std::allocator<SfxBroadcaster*> > >::_Safe_iterator(std::__cxx1998::_Deque_iterator<SfxBroadcaster*, SfxBroadcaster*&, SfxBroadcaster**> const&, std::__debug::deque<SfxBroadcaster*, std::allocator<SfxBroadcaster*> > const*) (this=0x7ffedb73c598, __i=, __seq=0x2acc2a0) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/safe_iterator.h:152
[...]
> #44 0x00002ae846166609 in chart::VCartesianCoordinateSystem::~VCartesianCoordinateSystem() (this=0x28c2b60) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/axes/VCartesianCoordinateSystem.cxx:64
> #45 0x00002ae8461767af in std::default_delete<chart::VCoordinateSystem>::operator()(chart::VCoordinateSystem*) const (this=0x28e4190, __ptr=0x28c2b60) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/unique_ptr.h:67
> #46 0x00002ae8461737d3 in std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >::~unique_ptr() (this=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/unique_ptr.h:184
> #47 0x00002ae84626e295 in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__pointer=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:93
> #48 0x00002ae84626e25f in std::_Destroy_aux<false>::__destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*>(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:103
> #49 0x00002ae84626e1bd in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*>(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:126
> #50 0x00002ae84626dce1 in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >&) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:151
> #51 0x00002ae846273bf3 in std::__cxx1998::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::_M_erase_at_end(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (this=0x2633240, __pos=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_vector.h:1352
> #52 0x00002ae846273b94 in std::__cxx1998::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::clear() (this=0x2633240) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_vector.h:1126
> #53 0x00002ae846251d8c in std::__debug::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::clear() (this=0x2633240) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/vector:563
> #54 0x00002ae84623749c in chart::ChartView::impl_deleteCoordinateSystems() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:1136
> #55 0x00002ae846240346 in chart::ChartView::createShapes() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2484
> #56 0x00002ae84623d8f6 in chart::ChartView::impl_updateView(bool) (this=0x2633140, bCheckLockedCtrler=true) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2563
> #57 0x00002ae846243eae in chart::ChartView::update() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2720
> #58 0x00002ae845bafef5 in chart::ChartController::execute_Paint(OutputDevice&, tools::Rectangle const&) (this=0x2a60ac0, rRenderContext=..., rRect=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/main/ChartController_Window.cxx:479
> #59 0x00002ae845bceb26 in chart::ChartWindow::Paint(OutputDevice&, tools::Rectangle const&) (this=0x2928e60, rRenderContext=..., rRect=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/main/ChartWindow.cxx:100
[...]
> #71 0x00002ae8280ee03c in Scheduler::ProcessTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/scheduler.cxx:451
> #72 0x00002ae8280ed1ed in Scheduler::CallbackTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/scheduler.cxx:270
> #73 0x00002ae828302716 in SalTimer::CallCallback() (this=0x20db780) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/inc/saltimer.hxx:55
> #74 0x00002ae828300b84 in SvpSalInstance::CheckTimeout(bool) (this=0x12640d0, bExecuteTimers=true) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/headless/svpinst.cxx:206
> #75 0x00002ae828301a61 in SvpSalInstance::DoYield(bool, bool) (this=0x12640d0, bWait=true, bHandleAllCurrentEvents=false) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/headless/svpinst.cxx:418
> #76 0x00002ae82811fbd1 in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/svapp.cxx:471
[...]
> Thread 1 (Thread 0x2ae842779700 (LWP 13177)):
> #0 0x00002ae8461307dc in com::sun::star::uno::Reference<com::sun::star::chart2::XScaling>::set(com::sun::star::chart2::XScaling*) (this=0x2ae842776bb8, pInterface=0x9999999999999999) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/include/com/sun/star/uno/Reference.hxx:234
> #1 0x00002ae84612f8a0 in com::sun::star::uno::Reference<com::sun::star::chart2::XScaling>::operator=(com::sun::star::uno::Reference<com::sun::star::chart2::XScaling> const&) (this=0x2ae842776bb8, rRef=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/include/com/sun/star/uno/Reference.hxx:349
> #2 0x00002ae846140bea in chart::ExplicitScaleData::operator=(chart::ExplicitScaleData const&) (this=0x2ae842776b98) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/inc/chartview/ExplicitScaleValues.hxx:37
> #3 0x00002ae846171ad2 in chart::VCoordinateSystem::getExplicitScale(int, int) const (this=0x28c2b60, nDimensionIndex=1, nAxisIndex=0) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/axes/VCoordinateSystem.cxx:272
> #4 0x00002ae84623d475 in chart::ChartView::getExplicitValuesForAxis(com::sun::star::uno::Reference<com::sun::star::chart2::XAxis>, chart::ExplicitScaleData&, chart::ExplicitIncrementData&) (this=0x2633140, xAxis=..., rExplicitScale=..., rExplicitIncrement=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:1735
> #5 0x00002ae845954d69 in chart::wrapper::Chart2ModelContact::getExplicitValuesForAxis(com::sun::star::uno::Reference<com::sun::star::chart2::XAxis> const&, chart::ExplicitScaleData&, chart::ExplicitIncrementData&) (this=0x26b6920, xAxis=..., rOutExplicitScale=..., rOutExplicitIncrement=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/Chart2ModelContact.cxx:143
> #6 0x00002ae8459d1d20 in chart::wrapper::WrappedScaleProperty::getPropertyValue(chart::wrapper::WrappedScaleProperty::tScaleProperty, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, eScaleProperty=chart::wrapper::WrappedScaleProperty::SCALE_PROP_STEPMAIN, xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:389
> #7 0x00002ae8459d114b in chart::wrapper::WrappedScaleProperty::setPropertyValue(chart::wrapper::WrappedScaleProperty::tScaleProperty, com::sun::star::uno::Any const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, eScaleProperty=chart::wrapper::WrappedScaleProperty::SCALE_PROP_AUTO_STEPMAIN, rOuterValue=..., xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:234
> #8 0x00002ae8459d0893 in chart::wrapper::WrappedScaleProperty::setPropertyValue(com::sun::star::uno::Any const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, rOuterValue=..., xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:130
> #9 0x00002ae846523605 in chart::WrappedPropertySet::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) (this=0x2b64cc0, rPropertyName=..., rValue=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/tools/WrappedPropertySet.cxx:89
> #10 0x00002ae841d97854 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x2b64cf8, nVtableIndex=4, pRegisterReturn=0x0, pReturnTypeRef=0x127fb10, bSimpleReturn=true, pStack=0x2ae8427777d0, nStack=0, pGPR=0x2ae842777ae0, pFPR=0x2ae842777aa0) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
[...]
Change-Id: Id0236bf04bff9f06f8fc5ee9e2db295216a54c16
Reviewed-on: https://gerrit.libreoffice.org/60474
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I7bfeef47abaf94cfb355db95c0fdb928ce36c0a6
Reviewed-on: https://gerrit.libreoffice.org/60232
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I5f445522e9a1ccd60555e992adf345b254b2ac83
Reviewed-on: https://gerrit.libreoffice.org/60335
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
With adding the "TextMaximumFrameWidth" property to the chart title's
textbox property, it breaks chart titles longer then the chart width,
as in OOXML reference implementation. LibreOffice previously distorted
the text and squeezed the chart. This patch will fix it.
Change-Id: Ic086d25b49e9c5cf9c6f2c79f141592749adc7d8
Reviewed-on: https://gerrit.libreoffice.org/59991
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Idd435b3a4d081f6d3af26ff8add69ad4af50db57
warning: calling a base constructor other than the copy constructor
Reviewed-on: https://gerrit.libreoffice.org/60239
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If678c5f4834144f1c710465701dc4d13714a6b44
Reviewed-on: https://gerrit.libreoffice.org/60247
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ia6ec954c6d0117fddc17432301ddeda3b26bbc8e
Reviewed-on: https://gerrit.libreoffice.org/60222
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit 3d604d1cd6cc70ef96782ef769f0479b509987a8.
comments from sberg:
I assume dropping the std::move from aCurSel(std::move(aSel)) is caused
by performance-move-const-arg's warning "if std::move() is called with
an argument of a trivially-copyable type"
(<https://clang.llvm.org/extra/clang-tidy/checks/performance-move-const-arg.html>).
For my taste, that approach is too tightly tied to a class's current
implementation details, something that may change over time. Imagine a
trivially copyable class C with a raw pointer member (where the
lifecycle of the pointed-to object is tracked by some higher-level,
likely broken protocol). Now, that protocol is fixed and the raw
pointer member is replaced with a std::shared_ptr. C is no longer
trivially copyable, and the dropped std::move would turn out to be
beneficial again.
(Also, if Clang and clang-tidy did implement the fixed rules for
trivially copyable classes from CWG1734/C++17, where a subset of a
trivially copyable class's copy/move members may be deleted, the above
rule to warn "if std::move() is called with an argument of a
trivially-copyable type" would no longer make sense as written; consider
a trivially copyable class whose copy ctor has been deleted.)
Change-Id: Icb91610e50ed98b8f55fe6323bdfa48c8cb9b4b9
Reviewed-on: https://gerrit.libreoffice.org/60166
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I02eba1df117a9d0df42bcac13c3251cb4fa6da14
Reviewed-on: https://gerrit.libreoffice.org/60074
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I369d6755d3de2dd885214115559150256298852d
Reviewed-on: https://gerrit.libreoffice.org/60051
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I33d3ac3edbda5e2a9958373123565e28210b55c8
Reviewed-on: https://gerrit.libreoffice.org/59956
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I69247498e13331f6ef84afeb242479f8fb1178a8
Reviewed-on: https://gerrit.libreoffice.org/60068
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I607891e120688b746c8a4c577018d97147a79217
Reviewed-on: https://gerrit.libreoffice.org/60029
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iebcaea7b08c5284946d83b6b6b9ed26b218025d4
Reviewed-on: https://gerrit.libreoffice.org/59992
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
convert the LINK we use here to std::function, since LINK
does not currently handle std::unique_ptr
Change-Id: I9df80352e612445e5f5ca513d7d4196d65589778
Reviewed-on: https://gerrit.libreoffice.org/59804
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...when MSVC creates ExplicitCategoriesProvider's implicit copy functions (and
--disable-pch doesn't happen to include the definition of XLabeledDataSequence
anyway). Easiest fix is to explicitly delete those (apparently unused) copy
functions.
Change-Id: I983a7f20729ba066b4fa5342800382d830492848
Reviewed-on: https://gerrit.libreoffice.org/59830
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and return std::unique_ptr
Not that it helps much, the ownership quickly becomes complex once it
hits the TransferableHelper.
Change-Id: I3c6bd72072e092b71b32e4105fe859fdcea956af
Reviewed-on: https://gerrit.libreoffice.org/59777
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf82d475825b4794dadad50093839fad319e3ba5
Reviewed-on: https://gerrit.libreoffice.org/59527
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icc820a47ac891c358883f9c01224f676c58fdd11
Reviewed-on: https://gerrit.libreoffice.org/59744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I528f22876497f87159e3b9453362ebbfb55b7092
|
|
look for places where we are appending the temporary result of adding
strings together, to an OUStringBuffer, where we could rather call
append repeatedly and avoid the temporary creation
Change-Id: I481435124291ac7fb54b91a78344a9fe5b379a82
Reviewed-on: https://gerrit.libreoffice.org/59708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I25077e391ecca1b678062d261a83d88daadf0a58
Reviewed-on: https://gerrit.libreoffice.org/59701
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Some only-recently analyzed files were cleaned.
Also tried harder to use more fw decls instead of blacklisting
Change-Id: Ie4f8eb7065e44a2b5208d6da4fa8e3681a31820b
Reviewed-on: https://gerrit.libreoffice.org/59420
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
since it has nothing to do with the headless command line option, so
use the name it has in the configure.ac file
Change-Id: Ibf0615ed02695d6e48a797f5632e4f417c010c70
Reviewed-on: https://gerrit.libreoffice.org/59611
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Export the Overlap value with 100% for stacked charts, because the
default overlap value of the Bar/Column chart is 0% and LibreOffice
do nothing with the overlap value in Stacked Chart case, unlike the
MS Office.
Change-Id: If4e20b88c2b1180f68a8d2b610c407d674a8498b
Reviewed-on: https://gerrit.libreoffice.org/59448
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Jenkins
|
|
keep the performance fix of i#66963 but clip it to a value
larger than appears in that document, but massively smaller
than what is necessary for this document
Change-Id: I162c03a13ce11e348db8168fed212dfea216c7a4
Reviewed-on: https://gerrit.libreoffice.org/59458
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idec568c868411056d1c8aa1a93c36008b223ce57
Reviewed-on: https://gerrit.libreoffice.org/59356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I095ae98b809c1dc938c12b5fbe4427fb08edc604
Reviewed-on: https://gerrit.libreoffice.org/59353
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I641d93e54504c27bcc49bae8edf6286c0a9a471f
Reviewed-on: https://gerrit.libreoffice.org/59024
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2bcfeb1e670bc75f093a05e7d5bfb0be09235052
Reviewed-on: https://gerrit.libreoffice.org/59023
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4506a3517eff7f73cf793195e9d605d450b84fda
Reviewed-on: https://gerrit.libreoffice.org/58995
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9cc607bcc84a14ffdbe22bdbe1a038f5b22b719a
Reviewed-on: https://gerrit.libreoffice.org/58871
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I76ad0b3152030c29ee28f6a6cc80d0832188d02b
Reviewed-on: https://gerrit.libreoffice.org/58774
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If the color or other property of a datapoint in the chart
deviates from the dataseries property, this patch will write it
into a separate dPt tag and fixing the lost properies during
OOXML export.
Change-Id: I3d975675ac3691fcafe76de16e46851561eb2807
Reviewed-on: https://gerrit.libreoffice.org/58752
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Try harder to use fw declarations, and a few newly analyzed files
Change-Id: I50299e9115ced60468c7bc5e63013addbaec48c0
Reviewed-on: https://gerrit.libreoffice.org/58618
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|