uno::Reference is only allowed to used with classes that have a
::static_type member.
So convert all those places to rtl::Reference.
Maybe we need some LIBO_INTERNAL_ONLY constructors on rtl::Reference and
uno::Reference to make this a little smoother?
Change-Id: Icdcb35d71ca40a87b1dc474096776412adbfc7e3
Reviewed-on: https://gerrit.libreoffice.org/25516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
...which itself only contains a "break" (or nothing at all at the end of the
"switch"), as otherwise Clang -Wimplicit-fallthrough would warn about these.
Change-Id: I25c1cf2ca74dfeba7ca0385ca8f1c1bf30bbf91b
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. But on a quick look at
least, it looks like none of the mangled C++ symbols in the stable URE
interface actually depend on wchar_t.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Searched source for using declarations.
Checked if those symbols reappear in the source file,
even in comments or dead code but not in #include statements.
If they don't reappear, remove the declaration.
Remove includes whose symbol got removed.
Change-Id: Ibb77163f63c1120070e9518e3dc0a78c6c59fab0
Reviewed-on: https://gerrit.libreoffice.org/24148
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
and x86 has smaller alignment than arm or a x86_64 host,
so needs the MAX_ALIGNMENT_4 to not trigger the static_asserts
Change-Id: I5643a33e4975e7bad20693f99fb8bbd5248c7c1c
I corrected the mistake that i did while converting OSL_ENSURE to
SAL_WARN_IF while submitting a patch regarding removing OSL_DEBUG_LEVEL > 1
conditionals. Thanks to Julien Nabet :)
Change-Id: I374373bf151a43b1ababf4c28b509da71068f755
Reviewed-on: https://gerrit.libreoffice.org/23112
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.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>
GCC in Ilumos appears to behave exactly like the Solaris SUNPRO
compiler so generalize the case for Solaris.
(cherry picked from commit e1da117c49fc02af9543e32526bf1c04657534c4)
Change-Id: I3fa619f34c35608b187c3aa394552ac78c3f0c20
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case.
It turns out that sal_Unicode happens to not be mangled into any symbols that
make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are
free to replace the typedef to sal_uInt16 with a typedef to any integral type
layout-compatible with that. (sal_Unicode does appear in some symbols in sal's
PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc
libraries, so changing those symbols does not require a change of SONAME.)
C++11 chart16_t is the obvious choice (and will ultimately allow using u"..."
to write literals of type array-of-sal_Unicode). Reportedly, char16_t is
supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015.
For plain C, we continue to use sal_uInt16. We could theoretically use C11
char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not
offer that C11 header.
For MSVC, we continue to use wchar_t (which is actually unsigned short, due to
/Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t-
and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is
dropped.
Some code needed to be adapted that was written in a way assuming that
sal_Unicode is unsigned short (which indicates that changing sal_Unicode for
non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now
differentiate between being called with sal_Unicode (to append a single
character) and erroneously being called with sal_uInt16 (intending to append a
number's textual representation, for which the sal_Int32 overload must be used
instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that
this code wants to append a number, not a character" and
dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the
numerical representation."
The GDB support for pretty-printing of sal_Unicode-related data in
solenv/gdb/libreoffice/sal.py can presumably be simplified now.
Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401
Reviewed-on: https://gerrit.libreoffice.org/20036
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
