"thumbviewer.cxx(168,9) : error: delete called on 'StreamOnZipBuffer' that has
virtual functions but non-virtual destructor"
Change-Id: I34510d54b9a99d8f1f9e8da0236625023c3fd94c
...since ce59f8851472776f2ea364f7597ac887e77081c5 "INTEGRATION: CWS
desktintgr03: #i34294#" commented out the uses (whicht got later removed
completely with 45f0cc2ec176f02592a4e67942b1220f7837ab9f "Remove commented code
in libs-core/shell")
Change-Id: Icb7f97b72634d07045f5880af33b372be36e66b2
...which does not behave as expected with the given command line arguments, so
just strip "-cl.exe" (and any hard-coded command line arguments following it in
$CC, but that's probably rather harmless here). Expects that clang-cl is given
with an ".exe" extension in $CC (not assuming that and stripping "-cl" and
everything that might follow could be a bit too agressive).
Change-Id: If99f964dda1369b7d4bbb63b3d634b93c9f935a8
...for size_t (i.e., unsigned long long on Windows 64-bit), chosing among the
int, unsigned int, long, unsigned long overloads. MSVC apparently happily picks
one of them, but clang-cl rightly complains.
Change-Id: Ib245925bdf9e4a34add6ca435a95559f4f07c4d7
...apparently a copy of MSO_ShadeType removed with
e336d7f80fd9f7ada4b12c37f9434df411d28466 "Remove unused MSO_ShadeType" and
equally unused
Change-Id: If1660faa45c1445c302ac0c9a1a160674691c15d
...otherwise, as the class is SVX_DLLPUBLIC and---for better or worse---
SVX_DLLPUBLIC is shared between Library_svxcore and Library_svxcore, all .cxx in
Library_svx that happen to include cell.hxx would emit them (as well as those in
Library_svxcore, of course), and the copy ctor requires the vtable, which in
turn requires an adjustor thunk for Cell::getPropertyStates, which happens to
not be emitted into any of the Library_svx .cxx that require it under clang-cl
due to <https://llvm.org/bugs/show_bug.cgi?id=25641> "clang-cl: vtordisp thunks
not emitted for functions with class template specializations in their
signatures."
Change-Id: Ib03b7002f9dfe3c2df742640ef7406cf24a7cecd
...otherwise, as the class is SVX_DLLPUBLIC and---for better or worse---
SVX_DLLPUBLIC is shared between Library_svxcore and Library_svx, all .cxx in
Library_svxcore that happen to include svx/pageitem.hxx would emit it (as well
as those in Library_svx, of course). But at least clang-cl at /O0 would want
to put SvxPageItem's (base-class) vtable in place in the dtor, so would also
emit the vtable, so would depend on SvxPageItem::operator==, but that is defined
in pageitem.cxx in Library_svx, against which Library_svxcore doesn't link.
Change-Id: Ibfc393c1de3e0bd6621c057d88b1b0f272820154
...for C-style cast from 'connectivity::ado::OLEString' to 'rtl::OUString', as
connectivity::ado::OLEString has conversion operators to both OUString and BSTR
(i.e., wchar_t*), so both the OUString copy ctor and
OUString(sal_Unicode const*) ctor match. At least MSVC 2013 happily compiles
that without complaining, but clang-cl does.
Change-Id: Ica634cf19c0fcf1dbff377cb503f6ea6c8257898
...as the source files themselves include standard headers, which must not be
included from within a namespace (which confuses clang-cl). According to Tor,
the original intent was to try not to pollute the global namespace, but that
seems to cause no problems in practice (esp. as nothing from these files gets
exported).
Change-Id: I204c1db932996a09d16e84dd5c6033caa5362caa
