There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Always _WIN32 is defined, even in Win64. So the check must be to _WIN64 and then to _WIN32.
Hope no more lines like this in code.
Can you test programs with SDK 64 Bit?
...as clang-cl doesn't support the /clr switch.
* In configure.ac, capture the MSCV version (that would be used if CC hadn't
been overridden to use clang-cl) into MSVC_CXX.
* The logic which flags to pass into gb_CObject__command_pattern is coded into
the platform-agnostic LinkTarget.mk, so it's too late to try and filter all
relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is
a normal one built with the normal $CXX or a special /clr one built with
$MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures
this information early.
* When building with clang-cl, the generated config_host/config_*.h files
contain values suitable for clang-cl, but not for MSVC. But the .cxx files
compiled with MSVC happen to include config_global.h, and would fail. Hack
around that problem for now by introducing a hard-coded, minimal
solenv/clang-cl/config_global.h that is found first when buliding such a
CxxClrObject. Needs cleaning-up properly.
Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33
Reviewed-on: https://gerrit.libreoffice.org/34509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This seems to be a good idea based on several discussions
in the project. In the end catching SEH exceptions is just
going to cause strange platform dependent bahavior.
This patch is based on on
http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.scm/39102/focus=55516
and includes some additional cleanup of the sal signal code.
Change-Id: Iedc998e37e6495afec445eccb60fa1c2b1a7defd
Reviewed-on: https://gerrit.libreoffice.org/26497
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
This should fix build failures due to file locking preventing concurrent
access to cli_ure/source/cliuno.snk.
Change-Id: Iefd16ed83a01523b3612844c2f777516dc4e44c6
...to avoid lots of loplugin:staticmethods warnings. Also enables DBG_ASSERT
etc. also for --enable-debug builds in addition to --enable-dbgutil builds.
Change-Id: Ib89ecd9ab8ce7abb2c64790ace248b31f9d2b64d
The order in which the hash table of incomplete structure types is
iterated is non-deterministic. Make sure that the array fields are
complete types before they are assigned.
This fixed weird error on Windows 64 bit. The reason this bug wasn't
hitting on 32 bit Windows build is because the generation order was
different and by chance the referenced fields were already generated.
Change-Id: Ifc8622b420fc25fea5a0ac8c09d08f7804c9b77c
Reviewed-on: https://gerrit.libreoffice.org/13851
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
This addresses some cppcheck warnings.
Change-Id: Ib35eb591534c3f23adc3cb7b7fa9696dc5cbeabf
Reviewed-on: https://gerrit.libreoffice.org/13383
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
Sadly cannot forward declare "struct {...} TimeValue;".
rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h
was painful enough for now...
Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05
It turns out that almost none of them were necessary.
Change-Id: I1311ed28409c682b57ea8d149bcbaf2c49133e83
Reviewed-on: https://gerrit.libreoffice.org/12133
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
commit 4b56d82c7d20ba5897d87aaf7fc94da5356b8eec converted the cli_uno
library from "Managed C++" to "C++/CLI", but forgot one detail:
The destructors on "ref" classes were mapped to Finalize() methods in
the old syntax, but the new one maps them to Dispose() methods, which
are only invoked on stack-allocated objects. Presumably this omission
results in leaking of native C++ UNO objects.
Reading the C++/CLI documentation i get the impression that:
1) the destructor should explicitly call the finalizer
2) the CLR will not call the finalizer itself iff the destructor is
invoked
http://msdn.microsoft.com/en-us/library/ms235315.aspxhttp://msdn.microsoft.com/en-us/library/ke3a209d%28v=vs.110%29.aspx
Change-Id: I509d9b69a399c3d7d6597060ab9b7c78c5916e11
Reviewed-on: https://gerrit.libreoffice.org/11132
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
