Age | Commit message (Collapse) | Author |
|
(in an attempt to cause tinderboxes to rebuild)
Change-Id: I5cc94a988303b7b1ff85ec09c3d4f88d300f73b0
|
|
Change-Id: I2fdbc2ac10f483eee154bdf69479ba217a91ef7f
Reviewed-on: https://gerrit.libreoffice.org/19605
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: Ifa66e63e67d6ae0a6453d86634e2aa998c442adc
|
|
Change-Id: I6f7d7d3b5b027097417a15804a42aaaab4a03158
Reviewed-on: https://gerrit.libreoffice.org/20185
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: Ibffaa2e3924877b22abbcd17aaa8fac01607f639
|
|
Change-Id: Ib1f06cb5f925535858bc14aab6f59ad7fd2a3a8d
|
|
Change-Id: I2220ab194384fb397716bf3227d38716ba54f537
|
|
...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: I22f1205396c502b6d3e937343e2ea9698b756f77
|
|
Change-Id: I85ed86fdd8b11863c96b7a6c3ba76d77dbecf192
|
|
Change-Id: Ibc5462642d0a3cd0f96668472ddc0ac0ae407132
|
|
Change-Id: I53c746be98972c7024dc2f340738182e46c24241
|
|
That literal %s was irritating.
Change-Id: I2925b26b1f3d1c101106ca616d18b24b41210c72
|
|
See https://wiki.documentfoundation.org/Development/Emscripten for details
Change-Id: I977a8b9e98b9be13c263fef48f567b92347d0492
Reviewed-on: https://gerrit.libreoffice.org/18643
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I882c04fd3a255f55511b1884157de26e7574e6db
Reviewed-on: https://gerrit.libreoffice.org/18262
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
configure.ac was setting VERBOSE=YES/NO when really
we use verbose=t or verbose=
Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299
Reviewed-on: https://gerrit.libreoffice.org/17634
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
The change to sal/log.hxx affects extensions too which are not required
to use a C++11 compiler.
Change-Id: I3ed08f9a02a2e082fcdb821bce84244597f2390a
|
|
Change-Id: Ifbd87e59fa91241dd5852f7dc6b63e65d8ca6bad
|
|
Work in progress to allow integration of LO with
<https://wiki.gnome.org/Projects/FleetCommander>.
During configuration, dconf support is implicitly enabled when available on the
host (which is presumably only available on Linux). It is explicitly disabled
for TDF Linux builds for now, though, to avoid accidental dependencies of the
distributed installation sets on system dconf libraries.
A dconf layer is represented in the CONFIGURATION_LAYERS bootstrap variable with
type "dconf" and an empty URL. See the comment at the top of
configmgr/source/readdconflayer.cxx for the encoding of component-data in dconf.
All of this is still subject to change.
Change-Id: I2d08d81c8ea43ba4a99040a8882ae75b91bcfdb9
Reviewed-on: https://gerrit.libreoffice.org/16848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that should have been removed as part of
7196df7ac616be39689f21d8784fd78030868586 "tdf#43157: Enable format check in
sal_detail_logFormat"
Change-Id: I331359bfa0e7c678f662f3de63257ccc0b528484
|
|
Change-Id: Ia3cd8a2f0979f2312a70b8ee169fe9d6eef85c81
|
|
With 64-bit MSVC, sizeof(long) is 4 but sizeof(void*) is 8, so this
would select sal_uInt64 but SAL_MAX_UINT32.
This should make sizeof(sal_Size) the same as sizeof(size_t) on all
supported platforms, but still sal_Size maps to different integer
type (long vs. int) than size_t on 32-bit.
Change-Id: I638aac6b502e624ed6b01f5921e20bc40f42480c
|
|
Change-Id: I1c76d4ce91d1f22d88106918ab139b17f6f017f0
|
|
Change-Id: Idb2e46fcaa080d6763d2e3ed963f7673a2353eb2
|
|
Change-Id: Ice8504041f22e00f2e5010813d9dff1d2987c8d6
|
|
Change-Id: I6b46eea0890573166d8a49e8060716907f223a1d
|
|
Change-Id: I65296dd9b4b13fc1c3a3d8eed738e257b204b691
|
|
...for a 32-bit build, similar to what ee11e221d2108212619e1bbe7f029e7d9afdba32
"tdf#43157: Fix format string violations in OSL_TRACE etc." did for a 64-bit
build
Change-Id: I05dd79ede3e66cb9ab7a33792319eb34b34c82dd
|
|
When a file's time is epoch (1970-01-01 00:00:00, i.e., TimeValue temp is all
zero) and the TZ is UTC or westward, osl_getLocalTimeFromSystemTime returns
false and leaves myLocalTime uninitialized. That e.g. confuses getModuleByUrl
(scripting/source/pyprov/pythonscript.py), potentially re-loading a Python
script with epoch time (as happens e.g. for the share/Scripts/python/ files in
an xdg-app installation of LO) every time it is accessed, falsely assuming it
has changed on disk since last load.
Change-Id: I8d4228feb28e2697a7021e3488ae2c09e8439ed8
|
|
Work in progress. The selection not used for anything yet.
Change-Id: Ia86fa0f59dcfee8e9d332a028a3fad37f4019fe0
|
|
"[...] to allow users to control the visibility of a type for the purposes of
RTTI [...]"
(<http://llvm.org/viewvc/llvm-project?view=revision&revision=175587>), so fits
well for SAL_DLLPUBLIC_RTTI
Change-Id: I6494e027c3af176591ffeb1d6a8965b7d40db1a9
|
|
Change-Id: Id9bfb3886e4a9cbc15a7bf7ef3aefa73bd160e3b
|
|
Change-Id: Ic9cda5259db81dd921dd3fa891b1289b8283bf27
|
|
Change-Id: Ia0a4834987ae040a31e19276ece20b74b59ca445
|
|
Change-Id: Ib1ec1ae009115dcc8f50ca3038bc9a35b7cb09a9
|
|
...don't dare make it non-explicit, yet.
Along the way, introduce SAL_CONSTEXPR.
Change-Id: Ia3179d0d5e001fd7aa92237c97437e9b74366ee1
|
|
guess we'll need them more often..
Change-Id: I0ef149fc5edceee765419764bf0efa571ba9d977
|
|
Change-Id: I129f3dc1597035664e4ff284276cb0d49a560ab5
|
|
after paint"
(and its later fixup)
This reverts commits
e8a68c1f50f32a0f9d8bcdf16c1270c319910baa
e60b589952985edff12b1a28392ce6fa0ca8d9be
It was a work-around for the real underlying issue, which was that the
result of dbaccess::ResultSet::isFirst() et al were clobbered by moves
made by its clones.
The BrowseBox has two different cursors:
1) One for data to edit (which is kept on the current/active row)
2) One for data to *paint*
The second is a clone of the first.
The real underlying issue is fixed by:
commit d7c9a1d9d65fe8b1a56c5c280d2ca6640a549d2f
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date: Thu Jan 22 10:49:42 2015 +0100
fdo#88475 RowSetBase: reposition cache before interrogating it
Change-Id: I28d62673fdf10ee6507d38bb7c79c08e4b40902f
|
|
The Itanium C++ ABI mandates that for a unique (complete) C++ type a single
unique symbol for the type's RTTI name is used across a process's dynamic
objects (so type equivalence can be determined via pointer comparison on the
RTTI names).
GCC nowadays deviates from that, using strcmp to determine equivalence, so it is
resilient to RTTI names being bound locally within dynamic objects (which has
performance benefits, but also makes it impossible to have unrelated types that
happen to have the same name "encapsulated" in individual dynamic objects---
whether or not that would violate the ODR would be open to interpretation of how
dynamic objects fit into the C++ Standard).
LLVM sticks to the Itanium ABI, which becomes notable in at least two places:
For one, libc++abi's __dynamic_cast uses strict checking. It still has a
_LIBCXX_DYNAMIC_FALLBACK for now that additionally uses strcmp checking and
syslogs visibility violations. Mac OS X uses libc++abi with
_LIBCXX_DYNAMIC_FALLBACK enabled, and running LO routinely logs dynamic_cast
errors to the Console there.
For another, RTTI-based UBSan checks unconditionally only use strict checking
(cf. isDerivedFromAtOffset in lib/ubsan/ubsan_type_hash.cc). This causes false
positives from Clang -fsanitize=function and -fsanitize=vptr even on Linux not
using libc++abi.
Therefore, introduce SAL_DLLPUBLIC_RTTI to mark types for which RTTI needs to
have default visibility under the Itanium/LLVM semantics. There is
unfortunately no way to mark only the (implicitly generated) RTTI symbols for
default visibility, but at least with the cases where SAL_DLLPUBLIC_RTTI is used
for now that is no real problem---any class type marked SAL_DLLPUBLIC_RTTI only
has inline (covered by -fvisibility-inlines-hidden) or undefined pure virtual
functions. It appears that even the vtables of those classes remain hidden, at
least with Mach-O on Mac OS X. (That also means there is no need for a
SAL_DLLPRIVATE_RTTI marker analoguous to the---also superfluous in retrospect---
CPPU_GCC_DLLPRIVATE one.)
Nevertheless, the number of exported symbols of course increases when
SAL_DLLPUBLIC_RTTI is "active." For a full-blown --enable-dbgutil build on Mac
OS X,
find instdir/LibreOffice.app/Contents -name \*.dylib\* -exec nm -gU {} \; \
wc -l
increased from 125541 to 139239. For Linux, an option might be to "activate"
SAL_DLLPUBLIC_RTTI only for __clang__ plus !ENABLE_RUNTIME_OPTIMIZATIONS.
The set of types marked SAL_DLLPUBLIC_RTTI with this patch (wholesale cppumaker-
generated UNO enum, struct, and interface types; plus some IEmbeddedHelper and
IUndoManager) is chosen so that a full "make check" on Mac OS X no longer
syslogs any dynamic_cast errors to the Console.
Change-Id: I42fa6ec01c2503ec24bcd9c0518abb112afa3235
|
|
OSL_ENSURE does not execute in non-debug builds (and is deprecated).
Do not try to seek back if paint did not seek.
This happens in particular when there is no data source attached (and thus trying to seek fails).
Change-Id: I3f4908c4dcae2bb120bf58c1218e3386c40d5721
|
|
Change-Id: Ia6c178dd9390bf75a08c0d53e6505582a7f5ab4f
|
|
from 234e45bf1d27484b72e73fe327b1e92fda1933f1
Change-Id: Ic1bcab8a9662e2f302a24a6eaad2f813c12b28a8
|
|
This reverts commit 06a5b619a76c96783ee67bdcfd21f203d3ddb53c, which broke
Solaris/Illumos builds for no good reason, cf. mail thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2015-January/065844.html>
"4.4.0.1 build error on sal/types.h on solaris/illumos."
Conflicts:
include/sal/config.h
Change-Id: I063453ee1115ae3f97e2835828800c74e3cb5e48
|
|
...on Clang trunk towards 3.6, firing for typeid(*e) where e is a side-effecting
expression (of polymorphic pointer type). Simpler to disable it via #if in
sal/config.h than to disable it in solenv/gbuild/platform/com_GCC_defs.mk with
an additional feature test in configure.ac.
Change-Id: If94692a9e06ff2659bf168b4968200aeee9ebb0a
|
|
Change-Id: I6f4a6679c263ac81d1cf5c66f18782e857da5ff8
|
|
Change-Id: I37e507226e676ee797e6911a0b3da1d1823e750a
|
|
By the way an item of the following page suggests the same snipet:
<http://www.faqs.org/faqs/ui-builders/TeleUSE/>
while I am not sure if it was the case.
Change-Id: I9fb0ea0e872cb1697aa953a406527472f0cbccde
Reviewed-on: https://gerrit.libreoffice.org/12330
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ic76ccc49b9291fe82c56974eb6237cd3b85d91c8
|
|
This is supported in GCC 4.6.0 already:
https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html
Change-Id: I2f67e588eea3a323a2e9c81e39e56ab2e715a817
|