Age | Commit message (Collapse) | Author |
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
instead of passing around a Sequence<String>, there is no need
to use UNO types here.
Change-Id: I1b9a1b6919f830d8ce29139b4362b979a669d505
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107396
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which has never been used since creation in
commit fd069bee7e57ad529c3c0974559fd2d84ec3151a
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Mon Sep 18 16:07:07 2000 +0000
initial import
Change-Id: I1ead1bee759eb09eb72517d90b42813ad66ea1e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107373
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which has never been used since creation in
commit fd069bee7e57ad529c3c0974559fd2d84ec3151a
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Mon Sep 18 16:07:07 2000 +0000
initial import
Change-Id: I018b1f734c8263167dab3d5c6f98a400666f01d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107047
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I115fc0ed81d6392d3649757727c4d9468213619d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2e6cab798309a1bc2ade00661bc95dd5ae20f748
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107045
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
just use the struct instead of passing around sequence
of sequence of PropertyValue
Change-Id: Ic03c066962a10daac6f83f30413a5ab09e1bfd5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106915
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
changed font order priority.
1. put 'Noto Sans KR' ahead of 'Noto Sans CJK KR'.
Because, New Noto Sans CJK font change the name.
New Noto Sans CJK V2.001 released on 10 Apr 2019.
In these font files, removed 'CJK' on names.
Nowadays, New Linux distributions includes Noto CJK font V2.0.
In Korean Linux environments, Noto CJK font v2.0 'Noto Sans KR' & 'Noto Serif KR' are already set default.
2. fixed Windows fonts for Korean on LibreOffice
I watched Windows 10's Korean Font List
Microsoft Docs: Font List Windows 10 - Typography; Korean Supplemental Fonts
https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts
I missed 굴림체;GulimChe, 돋움체;DotumChe, 굴림체;GulimChe.
So. I added MS Default Korean fonts.
As a result, I changed font order and add default Windows font names.
Ref.
1: Google Noto CJK fonts Repository: https://github.com/googlefonts/noto-cjk
2: Microsoft Docs: Font List Windows's Korean supplemental fonts
https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts
cf.Apple Docs - Format Chinese, Japanese, or Korean text in Pages on Mac
https://support.apple.com/guide/pages/format-chinese-japanese-or-korean-text-tanfbd4156e/mac
Change-Id: I12594aa8f3122c05810a07a718aae7ec185ba481
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104189
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Store AddParaLineSpacingToTableCells in configuration as
"AddTableLineSpacing", consistently inconsistent like AddTableSpacing
(the <desc> elements are not subject to translation).
Adapt SwCompatibilityOptPage with some ugly hacks to allow 3 different
states (TriState) for the corresponding checkbox that map to false/false,
true/false and true/true.
The checkbox widget doesn't allow to change *to* indeterminate but at
least the status of the document can be displayed this way,
with a non-obvious tweak to optcompatpage.ui to reference "checktri1"
column.
Change-Id: I5f32e05c93b5e16e782cba5d1d055809d9e5e251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103318
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Between <https://github.com/llvm/llvm-project/commit/
0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound
punctuation tokens that are split across macro expansions or split by
whitespace" and <https://github.com/llvm/llvm-project/commit/
0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove
-Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::'
and '*' tokens forming pointer to member type are separated by whitespace"
warnings, so just clean those places up for good even if the warning would not
hit out of the box with any official Clang release.
Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...thereby fixing that it returns _sDefault instead of an empty string when
"version.ini (versionrc) doesn't exist"
Change-Id: Ie38afb6d87bd908f8a9773daaf5cee56751ae950
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The option to set it was removed in 5fdf2009d21fa220dfee70ea755bd698c16257a7,
and now the check is redundant - and even harmful until the remnants of the
setting is dropped from bootstrap.ini. Currently the dummy value found there
makes the About dialog miss the build id, and copying info to clipboard gives
<buildversion> instead of proper build id. Previously the string was always
empty in most builds (including TDF), which made the code proceed to buildid.
Bootstrap::getBuildVersion got unused now, and is removed.
Change-Id: If59e456655da29bb9421edc0e15d421829d0a02b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100957
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
f9e6d8d7c33a308f6f1c15929dd839de2abae3b5 "INTEGRATION: CWS nativefixer18:
fix: #124825# read build id from version.ini" from 2005 had left the previous
code to read from the bootsrap ini file as a fallback, presumably intended for
some (short) transition period.
(Plus loplugin:elidestringvar fallout. And fix the comment, which appears to
have been non-matching right from the start.)
Change-Id: Ia50228f4ae21e9f7ded48fe47d68fcd9931b090c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100967
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I85a91d24943430b42217ac91611f182059d8ec69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100919
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I2fad16061bca6dc3e57926863e7a3b71947a8ade
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100139
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibe3443531c83eb44080217b61f5746be9cce9c49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99695
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I17fd4156eb940fbdc925d9761301096e5349135f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99674
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iaab664770d96a7d197354949bbe6d82c248f1037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99648
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iab187468cf25b4a4afc7c79578677156ff224df9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99651
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9f4684834002d09fb5408e2b705dec37ffa498fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is both more compact code, and more efficient, since the insert
method can do smarter resizing
Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If77111b78496420514fb73d6d98d22e759282093
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I05b02a2f8b4b9091c7de0f7e98409d5b608ed250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94610
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... to configuration and UI.
The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and
stored as value "3" in configuration.
Adapt a few places related to DocumentDigitalSignatures etc. to new
default.
Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I31df6c4fd82c6f6d15bbe5228e92e5171cacba51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92410
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit d8ac55e3e53564aca4b0bade5a5b5cb01b4519b1.
Change-Id: Ib7cf67d5d0b7780dfde9453cdddb8f11ca5d3a6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90542
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...now that macOS builds are guaranteed to have std::optional since
358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The problem was that commit ef39938dea14666a5835b6ae85091c1010f8ae8d
temporarily added ODF 1.3 version strings to the optsavepage.ui,
just to get translations for them; unfortunately the dialog itself
was not adapted to the new values, so when you select them the
result is 0, or ODFVER_UNKNOWN... fortunately this was reverted
before 6.4.0.3.
The value ODFVER_UNKNOWN is very dubious and without an obvious purpose;
http://specs.openoffice.org/appwide/odf/odf_1-2_migration.odt
mentions it but provides no details.
Hence let's interpret it the same as ODFVER_LATEST for export purposes.
Also add the value ODFVER_012_EXT_COMPAT to the configuration, because
this is actually used.
Also fix a copypasta in SvtSaveOptions_Impl::IsReadOnly(), where the
wrong flag is checked for OdfDefaultVersion.
Change-Id: Ie276f0ef3cead3ffa016ba939aede74581fb0257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87900
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I0f8de0f78c7a8fb78d47ee5dfed09019b4eb5288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87357
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to make this code easier to read
Change-Id: Ia1ea52cd713572be768f7b505080c08f15f6c542
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87290
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie14ea8349e5dc698a11b3447429b3ca7cbab9bb3
Reviewed-on: https://gerrit.libreoffice.org/85774
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifc269d9996928085a3ab78033788465b4f029368
Reviewed-on: https://gerrit.libreoffice.org/85255
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which merely announce that the next declaration is a class
Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc
Reviewed-on: https://gerrit.libreoffice.org/84229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...in preparation for wholesale replacement of boost::optional with
o3tl::optional, which will be an alias for either std::optional or
boost::optional, and std::optional only has value_or.
boost::optional::value_or was added with <https://github.com/boostorg/optional/
commit/3984c9f9a157ef116cea69bc8bb20f433320eb61> "Added function value_or()",
which according to git-describe first appeared in tag boost-1.56.0. We appear
to have no strict Boost baseline (the closest we get is with
> [AC_MSG_ERROR(boost/spirit/include/classic_core.hpp not found. install boost >= 1.36)]
in configure.ac), and at least CentOS 7 TDF machine tb76 only has
boost-devel-1.53.0-27.el7.x86_64. However, any environment using Xcode < 10
that needs to make o3tl::optional fall back to boost::optional should use
--without-system-boost, and external/boost is currently at 1.69.0, so should be
safe.
ATTENTION: In isolation, this commit will break in any environment that uses
Boost older than 1.56.0. It requires the following commit introducing
o3tl::optional. (But doing these changes in individual commits was deemed more
valuable than supporting a hypothetical future git-bisect against an old Boost.)
Change-Id: Ib31affa3eebf0d0029d8620dc6abb7a60f6c7629
Reviewed-on: https://gerrit.libreoffice.org/84127
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
so I don't read the "then" block as being a sequential statements
Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c
Reviewed-on: https://gerrit.libreoffice.org/82069
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512.
Change-Id: I55fe36b31cd3d40f86e5729337a927cf920f2af6
Reviewed-on: https://gerrit.libreoffice.org/81960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by the simple expidient of putting asserts in
the resize routine. Where an explicit const size is used,
I started with 32 and kept doubling until that site
did not need resizing anymore.
Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4
Reviewed-on: https://gerrit.libreoffice.org/81138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...that had been missing because the plugin didn't implement postRun, so it
didn't report anything when run as part of the shared plugin. (But did report
the expected warnings when run as a standalone plugin during
CompilerTest_compilerplugins_clang.)
Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes
in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old
preallocation of a 20 character OStringBuffer might have prevented
buf.append( reinterpret_cast<char *>(escapedString), len -1 );
from potentially throwing std::bad_alloc, which would have caused escapedString
to be leaked. Even though that 20-character preallocation was likely just
random junk and not meant to address the potential leak, lets address it now.
Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900
Reviewed-on: https://gerrit.libreoffice.org/80925
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|