revert a couple of pieces of commit
5fe99ea3
"loplugin:unusedmethods in sw"

Change-Id: If1eb9c7f01dcdea7ef7059165470357d5186ff93

Change-Id: I2c24d06d9fad26c65fa13cdcaa2c3f908971106c

Change-Id: Ibbd5e50ffeeb061a30d6f0f09a393a67ba67421e
Reviewed-on: https://gerrit.libreoffice.org/21598Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>

Change-Id: If726008f6755db59b01784ad6b479bbfe2d23e96

Change-Id: I9b1aa86e3cb325b07158e3994a961db8ea4114d8

...and would thus error out with -Werror=pragmas?

Change-Id: I113c43bed4d6d0c03e4c3c68684c50fd386428d9

Change-Id: I7facae62c7ce0977e8c40d60720e4fe32460cd3d

Change-Id: I60f7817b1d5e32ad642076ea2a9f7b7522ebb1de

Change-Id: I9a067605f7c477f4e057338577a437cda7f2aa3d

Change-Id: I4613f013c39e439dd11d3abc3737511cb8788d4f

Our sal/cppunittester/cppunittester.cxx uses SAL_IMPLEMENT_MAIN, so forwards the
cmd line args to osl_setCommandArgs.  CppunitTest_libreofficekit_tiledrendering
(run via that cppunittester) starts LOK, which starts SVMain on a lo_startmain
thread, which calls deskopt::DispatchWatcher::executeDispatchRequests to process
any cmd line arg requests to open documents.  It sees the
libtest_libreofficekit_tiledrendering.so (or .dylib/.dll) passed to
cppunittester, and tries to open it as a LO document.  Type detection will
typically determine it is plain text that should be opened with Writer, which
will succeed.  But when the .so is built with GCC 6, it happens to be detected
as a MacPaint document, loading which fails, so that executeDispatchRequests
(desktop/source/app/dispatchwatcher.cxx) will call xDesktop->terminate(), which
unwinds that lo_startmain thread (DeInitVCL etc.).  But the main cppunittester
thread is still calling into LOK, which is under the assumption that VCL etc. is
still functional, and somewhat random crashes will happen.

Change-Id: Ie7b00e797a0f3223b3942bb63a31aa9c44370247

...otherwise, GCC 6 would aggressively inline ScValidationDlg destruction of the
VclPtr<ScValidationDlg> in ScValidityRefChildWin::ScValidityRefChildWin
(sc/source/ui/view/reffact.cxx, in sc library), checking whether the vtable
points at ~ScValidationDlg (instead of a derived class dtor) to directly inline
the ~ScValidationDlg code, which requires the ScValidateionDlg vtable (to store
it in the object's vtable during destruction), which requires the code of inline
virtual ScValidationDlg::dispose and ScValidationDlg::Close, which in turn need
the addresses of (non-inline) ScValidationDlg::RemoveRefDlg and
ScTPValidationValue::RemoveRefDlg, both defined in the scui library and not
exported from there.

Change-Id: I7eb96f42deb5edd844d91e999aa5511679302c01

As far as I see, the only use of aNormalizedEdgeVector is as a
parameter to areParallel(), and there is no need for that to be
normalized, is there?

Change-Id: I31ca09391894ab441e5b88dbdd636cf4b91ac5c2

"the compiler can assume that the address of ‘rItem’ will never be NULL"

Change-Id: I90a8a3074c2dab427b4bc6345ec4a824eb2ac249

...so take the same "= -1" approach in ScTable::CopyColHidden as was alreday
taken in ScTable::CopyRowHidden

Change-Id: I0155965f142bd33706a303fb154d46776e40ec62

"the compiler can assume that the address of ‘rDoc’ will always evaluate to
‘true’"

Change-Id: Ic5dc481b84efad679150d13002a360478474cb90

...or else using it with GCC 6 libstdc++ std::find causes compilation failures

Change-Id: I95e674922348f72fab6da8f049b2b4fcbdc74d07

Change-Id: Idcb4386f37d4f945301934e4f2e65d81cf1db2bd

Change-Id: I080315852db2f6e852f63f3965a2b7bf91529168

Change-Id: Ifc7b1d6675a8e8fb41dd47cc1282059c3790736f

Change-Id: Icd867709d9d41a9ea1846d2f6332dd6988241efb

GCC 6 libstdc++ checks for that in debug mode now

Change-Id: I879b1b5eb9b54ad19749e561c55333b0a084c699

...when throwing an exception from implicitly noexcept ~GErrorWrapper.  So make
~GErrorWrapper noexcept(false) and see that no code executed while a
GErrorWrapper instance is active on the stack would throw an exception.  But the
design of GErrorWrapper, to throw an exception from a dtor, is very brittle and
should be fixed.

Change-Id: Ib04ff2b0497c160dc7ee44c3354fa9619285ec88

Change-Id: I549116095255426dd2036a2122097567bf40a204

Change-Id: I287bd92314780cc644ae559d988b93c408531340

Change-Id: Id452bfac5c83f130a138e06984a0c79c37af70ac

Change-Id: Ic3eb073d11a395a81b90fd1a9292d6ecf2940c09

Change-Id: If7f606973eeae92994fa06efee2266ff5dffe384

Change-Id: If2c92108e1f19cd766b36dabd1c9e9215242de11

Change-Id: I0cb13cdfbff3bfda13c08cd34a0032121500b4a3
Reviewed-on: https://gerrit.libreoffice.org/21518Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

Change-Id: I6473f08eaac5eba5aaf1b00cfd2ee36f651e8b22

This brings FontAttributes into line with ImplFont and Font, which is
important to the refactoring work I am doing.

Change-Id: I08160992834f3732738b40aae9264df00443795a
Reviewed-on: https://gerrit.libreoffice.org/21576Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>

Change-Id: I9bc4d5dbef899a31f485123ec841f8d6585a4529

Change-Id: I854e2dd48b2f59b561c0d0cd3e52297046d25b96

This does not solve the difference in how Excel seems to handle the
arguments and calculation, but some corner case. See bug comment 6.

Change-Id: Ifa331e8552587c40e1486a08093ed0df92a9d245

Caused tinderbox breakage.

This reverts commit af6a3912.

Change-Id: If07d3bda667001b479f41b2319bfef2e15068072
Reviewed-on: https://gerrit.libreoffice.org/21593Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Seems to break the tinderbox, needs more work?

This reverts commit 6aaf1ec5.

Change-Id: I2d4cedac4081260c5147d8c11904d042c765e3a6
Reviewed-on: https://gerrit.libreoffice.org/21557Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I37a9a801c6bc885bdc5e0cbb9cd4ed527095acf8
Reviewed-on: https://gerrit.libreoffice.org/21587Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: Idd8a86710b9b93b317b28e092b5bee971645c346
Reviewed-on: https://gerrit.libreoffice.org/21583Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>