Turn the Link class into a template abstracting over the link's argument and
return types, but provide default template arguments that keep the generic,
unsafe "void* in, sal_IntPtr out" behvior. That way, individual uses of the
Link class can be updated over time.
All the related macros are duplicated with ..._TYPED counterparts, that
additionally take the RetType (except for LINK_TYPED, which manages to infer the
relevant types from the supplied Member).
(It would have been attractive to change the "untyped" LinkStubs from taking a
void* to a properly typed ArgType parameter, too, but that would cause
-fsanitize=function to flag uses of "untyped" Link::Call.)
Change-Id: I3b0140378bad99abbf240140ebb4a46a05d2d2f8
ie.
void f(void);
becomes
void f();
I used the following command to make the changes:
git grep -lP '\(\s*void\s*\)' -- *.cxx \
| xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;'
and ran it for both .cxx and .hxx files.
Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
Also fixes fdo#42899 and fdo#67685 in a different way; the previous fix
for fdo#42899 caused the problem with password-protected libraries for
which the password is not known: only the binary representation of the
BAISC module was stored, not the source code; by simply copying from the
source storage the problem can be avoided.
It would be possible to ask for the password when storing, but that
would not work when non-interactive (called via API).
An alternative fix would be to pass in the
SfxObjectShell::IsSetModifyEnabled() flag and actually reset the BASIC
library's modify flag correctly, but that requires adding a
parameter to XStorageBasedLibraryContainer::storeLibrariesToStorage().
(regression from af34774d260a68fc02cd78ba90dd8d4afaf1a2a4 )
Change-Id: I4701401f35171139fc2fe8d225d13d4e533091a0
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...that had originally been introduced to catch DBG_ASSERTs during smoketest,
but since made effectively unused when basing DBG_ASSERT on the sal/log.hxx
functionality, and obsoleted by the ongoing clean-up of using true assert where
appliable.
Change-Id: I2fb4f5d0873d29595b178057f83c1404c0085575
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
