Age | Commit message (Collapse) | Author |
|
Change-Id: I744788bde9778f85ccd9d7667e19d16842900a29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0507dd797cd5a35e0ae14f4b69ee4e172d08a71a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105681
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Change these back to consistently use the "..." form to include other UNO API
include files, for the benefit of external users of this API.
Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
|
|
Change-Id: I389542e18fcf71011f22919743b5280779f449fd
Reviewed-on: https://gerrit.libreoffice.org/35632
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
(to avoid warnings about undefined macros in external code)
Change-Id: Ie1007207b22c19a3d9d96f0f94070c32d417595a
|
|
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
Change-Id: I14c2dc0be12151b5d4ea2ba3b65030f6f4494905
|
|
...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>
|
|
Change-Id: Id2359f6ff4bddb2afbc0b346e17cd858f00179e3
|
|
Change-Id: I17eb40b2923793280ea220e519f97563c8490a19
|
|
Change-Id: I85e866fc5b52c3bbedd5b54549dba018b70be2f7
Reviewed-on: https://gerrit.libreoffice.org/19485
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I2d60f21219adfe9935ad69620f3a7bd856f96376
|
|
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
|
|
Change-Id: I88259ffaffc73979c240721d2db166c79d3085f1
|
|
...but does support std::remove_reference
Change-Id: I4a702efdea9aad91cee32aca08da755e482e4b88
|
|
...using C++11-only std::remove_reference, but decltype is also only C++11, so
3rd party C++03 code should have no need for it anyway. (Commits acutally
making use of it to follow shortly.)
Change-Id: I8dd7a64ca73d2082a3e7b74d3599848e65e81da5
|
|
Change-Id: Ia1ab134a0afbeeb3ae40264bd4233a47df26b734
|
|
Change-Id: I834eb4ecd0fa71caf6fa746901367fac8b538305
|
|
Change-Id: I4ed4004990f0e98a1095f3b7f4a6d9dac009a4eb
|
|
Change-Id: Iec1251648031afa9eddd7445135fb08dc74821bd
|
|
Unfortunately iwyu gets quite confused by the weird cyclic dependencies
between various foo.h/foo.hxx and cppumaker generated headers, so it's
not obvious if any improvement here is realistic...
Change-Id: I0bc66f98b146712e28cabc18d56c11c08418c721
|
|
Change-Id: I0d84545527195e0f8a48d4217cb332f2e46f2d09
|
|
Change-Id: Iebd9124daffe98b1e38dfa71d8b11f2452e3ddaa
Reviewed-on: https://gerrit.libreoffice.org/11226
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: I2f1909f953846f0d0b6fb402b4beb373bba8b2a8
|
|
|
|
i.e. convert "::sal_Bool" to "sal_Bool"
Change-Id: Ie5943aee4fee617bf2670655558927ed25b7e067
|
|
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Change-Id: I4c9a55f8c7d0f05fda617f9b33d93ce78bb8fbeb
|
|
While strictly speaking an incompatible change, it is extremely unlikely that
external code uses cppu::Enterable at all; this should always have been a
private URE implementation detail.
Change-Id: I2c3fe754fe6268b18ca03532229f3403736f6f6e
|
|
Change-Id: I4f66403c197bb94ec0ce178f949ece80bab1116f
|
|
Change-Id: I4bd729499aa8be58f04194656e35c1f79d5d4919
|
|
Change-Id: I86db12420f5d84e467db72585609f8f144f73dad
|
|
Change-Id: Icba422d99836518a1b662b15144bc9334bed1473
|
|
Change-Id: I059fbee385a109069c70f3869021c8e2ee48fee1
|
|
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d
Reviewed-on: https://gerrit.libreoffice.org/3499
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|