| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b
"EditUndoRemoveChars::GetStr must return a reference" and dubious code
0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to
update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies
directly fixed in this commit.
Introduces HAVE_CXX11_REF_QUALIFIER.
Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
|
|
|
|
| |
Change-Id: I8f4d7f8ebdfa0fb2c5a8efc676d1f66876b6daa9
|
|
|
|
| |
Change-Id: I85ed86fdd8b11863c96b7a6c3ba76d77dbecf192
|
|
|
|
| |
Change-Id: Ibc5462642d0a3cd0f96668472ddc0ac0ae407132
|
|
|
|
| |
Change-Id: I53c746be98972c7024dc2f340738182e46c24241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...at least from "g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)" with
--disable-debug, when a namespace-scope const variable with a "complex"
initializer declared in an include file remains unused.
Avoid that warning via SAL_CONSTEXPR, which in turn requires large parts of
o3tl::is_typed_flags to be SAL_CONSTEXPR, which in turn requires a new
HAVE_CXX14_CONSTEXPR to allow assert in constexpr functions, which in turn
requires using -std=c++14 instead of -std=c++11 where available, which in turn
(a) requires to /not/ use -std=c++14 if it would run into a bug between Clang
and libstdc++ discussed at <https://llvm.org/bugs/show_bug.cgi?id=24115>
"llvm-nm fails to build with gcc 5.1's libstdc++" (and which hits us in
sfx2/source/control/thumbnailview.cxx), and (b) requires a new
HAVE_CXX14_SIZED_DEALLOCATION to work around GCC 5.1 -Werror=sized-deallocation
(where Clang >= 3.7 only supports C++14 sized deallocation when explictly
enabled via -fsized-deallocation, btw).
This effectively reverts ff6462e6307e6924dc6c8178043ae9032f4b4152 "avoid unused
variable warning:" again.
Change-Id: I424e3561452a3e6d8c8a9604d6c737cab49840c4
Reviewed-on: https://gerrit.libreoffice.org/18918
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
|
|
|
|
|
|
| |
The compiler's __GNUC__ etc. need not match the libstdc++ version used (esp.
when using Clang as compiler), and libstdc++'s __GLIBCXX__ macro doesn't inrease
monotonically with version numbers, so resort to a configure check.
Change-Id: I06de6b68324169863f6f5c31ae5d855e8b04cd6b
|
|
|
|
| |
Change-Id: I98060f1adae0ba8ec03b2f0d6b0db6d5a1c0385c
|
|
|
|
|
|
|
|
| |
...don't dare make it non-explicit, yet.
Along the way, introduce SAL_CONSTEXPR.
Change-Id: Ia3179d0d5e001fd7aa92237c97437e9b74366ee1
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This has been supported by GCC and clang for a very long time.
Change-Id: I410a2b39004c932003f8cbefe935aedb109b1163
|
|
|
|
| |
Change-Id: I43ed776d52336b822aa6152f0f2a29e39303bb75
|
|
|
|
|
|
|
| |
Clang reports itself to be gcc4.2, so there fail there, instead use configure
checks.
Change-Id: Idb44a5c875b24a15546a6495de02a1b4af898443
|
|
|
|
|
|
|
| |
The warn_unused attribute has been upstream to GCC and Clang, so use it if present.
Still warn about STL types if those do not use it yet (which is the status as of now).
Change-Id: I3c003e44c08d1d141e23bba38cf92e663a5ac353
|
|
|
|
| |
Change-Id: Id13e77fe890301a8510952994a91853568a7aea6
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it is useful to use SAL_FINAL mainly as a documentation aid,
to make it clear to a code reader when a class is not expected to be
derived from, and when a virtual function is not expected to be
overridden in a derived class.
Possibly there is also some class of bugs that using SAL_FINAL will
help find?
Change-Id: I45002f020dcb52e8a9f2962ff98780f2b80627af
|
|
|
|
|
|
|
| |
Since we no longer support the old Apple SDK using gcc-4.0.1, we can
remove the cruft to work around its problems. Woohoo.
Change-Id: Idf275e76449443f1f0314e75dab993f213a77eb7
|
|
|
|
| |
Change-Id: I6cd70d885a3fe3ab53f7523d1a5da6ae30ee01e3
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...replacing hard-coded GCC version checks. Those checks that guard
#pragma GCC diagnostic ignored "-Wnon-virtual-dtor"
appear relevant only for GCC itself, not Clang (which used to fail the old
guards because it typically announces itself with a rather low
__GNUC__/__GNUC_MINOR__ version), see 6e67c03dc0225fc66343546b14e902b9d238b1a3
"Enable -Wnon-virtual-dtor for GCC 4.6"
Change-Id: I6bfa4d5caa6192e7a203ce829682bf6bb8d61a1b
|
|
|
|
|
|
| |
http://lists.freedesktop.org/archives/libreoffice/2013-March/047769.html
Change-Id: I81ed4500878ff3193e028410a1f0205e28d17fc3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...otherwise, at least with some --with-system-boost versions and C++11
compilers, like with Fedora's boost-1.50.0-4.fc18.x86_64 and
gcc-c++-4.7.2-8.fc18.x86_64, using this to copy-construct an instance of
boost::unordered::detail::ptr_node<std::pair<rtl::OUString,Bootstrap_Impl*>> in
the call to p_bootstrap_map->insert(...) in rtl_bootstrap_args_open
(sal/rtl/source/bootstrap.cxx) would memcopy the ptr_node and fail to call
rtl_uString_acquire, leading to memory corruption later on when
rtl_uString_release is called one time too often.
It is not entirely clear to me whether this is a shortcoming of the given Boost
version, but this patch solves the problem and brings rtl::Allocator::construct
in line with the (changed) Allocator requirements of C++11 anyway.
The problem potentially lurks with every use of rtl::Allocator, but only showed
now begining with LO 4.0 where e5111574fd904b38a3980ca4ea3d21cfcb22dea6 "Revert
'sb140: sb140: #i116981# clean up memory upon exit'" re-introduced code into
rtl_bootstrap_args_open that inserts into a boost::unordered_map that uses
rtl::Allocator.
Change-Id: I3be22f59a8eb49d31458480c27f3ce15803c7fd4
|
|
We have only been lucky so far that there hasn't been any compilation errors
caused by using the HOST platform config_*.h files also for the BUILD
platform. But as more and more information found out during configury is
stored in config_*.h files, sooner or later it will be a problem.
Move config/* to config_host/*. When not cross-compiling, the config_*.h files
in config_host expanded from config_*.h.in are all there is. When
cross-compiling, the generated config_*.h files for the BUILD platform are
put into a config_build folder.
Then use config_build when building the cross_toolset and config_host
otherwise.
Change-Id: I3c28cc83866bffd696b45d00dfb68e00bc2ae538
|