...by re-enabling the code temporarily #if'ed-out in
a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Remove useless member SmColorTokenTableEntry::cIdent
aColorTokenTableDVIPS renamed (make the loop enter in one line)
removed redundant code in visitors (related to color)
removed temporal variables on visitors (related to color)
removed temporal variables on mthmlexport (related to color)
removed redundant code in mathmlexport (related to color)
Since SmColorTokenTableEntry is used as pointer remove useless operators
Change-Id: Icef831711c95e4f9c23b29a3a3606dd9d6fcf6c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...like
> l10ntools/source/helper.cxx:19:69: error: replace function parameter of type 'const rtl::OString &' with 'std::string_view' [loplugin:stringviewparam]
> const OString& rText, const OString& rUnEscaped, const OString& rEscaped )
> ~~~~~~~~~~~~~~~^~~~~~~~
where the call to rEscaped.getLength(), which would otherwise suppress the
warning, is hidden inside an assert.
(Similar to aab0322580c87864a4f0c0af1fed07282c8dccbb "Disable
loplugin:casttovoid when --disable-assert-always-abort".)
Change-Id: Ie054f75317707757b1c6243c593f539d445a9fee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110331
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
So look through (implicit) O[U]String to string_view conversions for those
arguments.
Change-Id: I1101d3f681d227ad0a76a4477bf52a1a3898cfdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109926
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to look through template instantiations involving std::forward
motivated by
commit b1617acde182d1683bdfb529794d7456f8b4bf6d
drop RadioButton arg defaults
the nBits arg in builder.cxx was in the wrong place
Change-Id: I222ea2aeea6f44ae54839e824a247a8105392c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109789
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to make it more obvious that, since 63a68064bb33f180b8a231f7524d99405d910226
"make the Color constructors explicitly specify transparency", it should only be
called when the argument is known at compile-time to have no transparency/alpha
channel.
(This revealed a GCC bug causing bogus
> xmloff/source/chart/ColorPropertySet.cxx: In constructor ‘xmloff:💹:ColorPropertySet::ColorPropertySet(Color)’:
> xmloff/source/chart/ColorPropertySet.cxx:81:9: error: ‘this’ is not a constant expression
> 81 | m_nDefaultColor( 0x0099ccff ) // blue 8
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
so in configure.ac suppress HAVE_CPP_CONSTEVAL when the compiler is found
broken.)
Change-Id: I68df7bd5fbd9b2dcf2243b5a4bde4064d3d665fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109697
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Even though `llvm-config --cxxflags` does not reflect it, LLVM generally uses
-fvisibility-inlines-hidden on Unix-like platforms at least since <https:
//github.com/llvm/llvm-project/commit/6b43f1f40f644b896f44078872c0b93ec3afef67>
"[CMake] Support -fvisibility-inlines-hidden when LLVM_ENABLE_PIC=Off" debuting
in release/3.8.x.
At least with my build on macOS 11.1 ARM64 against recent LLVM 12 trunk, that
caused a mismatch between
> $ nm -m compilerplugins/clang/sharedvisitor/analyzer.o | grep __ZGVZNK5clang24TemplateTemplateParmDecl18getDefaultArgumentEvE7NoneLoc
> 0000000000028038 (__DATA,__data) weak external __ZGVZNK5clang24TemplateTemplateParmDecl18getDefaultArgumentEvE7NoneLoc
and
> $ nm -m ~/llvm/inst/lib/libclangAST.a\(JSONNodeDumper.cpp.o\) | grep __ZGVZNK5clang24TemplateTemplateParmDecl18getDefaultArgumentEvE7NoneLoc
> 000000000001ccf0 (__DATA,__data) weak private external __ZGVZNK5clang24TemplateTemplateParmDecl18getDefaultArgumentEvE7NoneLoc
etc., causing (albeit harmless) warnings
> [GEN] compilerplugins/clang/sharedvisitor/analyzer
> ld: warning: direct access in function 'clang::JSONNodeDumper::VisitTemplateTemplateParmDecl(clang::TemplateTemplateParmDecl const*)' from file '~/llvm/inst/lib/libclangAST.a(JSONNodeDumper.cpp.o)' to global weak symbol 'guard variable for clang::TemplateTemplateParmDecl::getDefaultArgument() const::NoneLoc' from file 'compilerplugins/clang/sharedvisitor/analyzer.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
[...]
-fvisibility-inline-hidden is presumably supported by all
$(COMPILER_PLUGINS_CXX) used on non-Windows platforms in the wild, so lets be
bold and add it unconditionally.
Change-Id: I0d405b4f57066baa098977e65e5ba4a3a47575c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109712
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(The use of isa_and_nonnull<> instead of isa<> is necessary for cases like
return (i_styleSettings.*i_getDefaultColor)();
in lcl_getEffectiveColor, svtools/source/table/gridtablerenderer.cxx.)
Change-Id: Iffc59b1146dd4ce13bbd3c8a6f46bd3c78a39344
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109663
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
GtkPrintWrapper stuff is dead since
commit ed07ec7606cb24cccaf6b7b81b2bd308debaa2e6
drop never completed GtkSalPrinter
Change-Id: Ia42e9bca020a9683ba247d466f743a0018e920f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It has grown recently and is going to grow more.
cfgitem.hxx has been moved and clangformated because it is not anymore in excludelist
Change-Id: I277837b2c0a90ae4e84028dc6e19962939c1aef3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108645
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to reduce the churn, we leave the existing constructor in place,
and add a clang plugin to detect when the value passed to the
existing constructor may contain transparency/alpha data.
i.e. we leave expressions like Color(0xffffff) alone, but
warn about any non-constant expression, and any expression
like Color(0xff000000)
Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This avoids clang-cl
> In file included from core/connectivity/source/drivers/ado/Aolevariant.cxx:20:
> connectivity/source/inc\ado/Aolevariant.hxx(72,40): error: replace function parameter of type 'const rtl::OUString &' with 'std::u16string_view' [loplugin:stringviewparam]
> OLEVariant(const OUString& us)
> ~~~~~~~~~~~~~~~~^~
which would make that OLEVariant ctor overload redundant with the existing
OLEVariant(std::u16string_view us);
overload, but with the OUString overload gone, implicit conversions from
OUString to OLEVariant would no longer work, e.g.,
> connectivity/source/drivers/ado/AColumn.cxx(184,76): error: no viable conversion from 'rtl::OUString' to 'const connectivity::ado::OLEVariant'
> OTools::putValue(m_aColumn.get_Properties(), sAdoPropertyName, getString(rValue));
> ^~~~~~~~~~~~~~~~~
Change-Id: I92a5cc29d9fd2a5ff1a951f79df64879d0f71743
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109180
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In practice, it works fine to look at all of them, regardless of actual argument
types.
Change-Id: Ifc49cbcd6003c8837c1b3f81d432c59fb0657bf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108366
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>
...as it causes Clang to fail with
> Assertion failed: (!isValueDependent() && "Expression evaluator can't be called on a dependent expression."), function isIntegerConstantExpr, file .../llvm/llvm-project/clang/lib/AST/ExprConstant.cpp, line 15487.
Change-Id: I335f7610955c30a5c102bfb3b8aa6441a30dd247
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108241
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Otherwise, clang-cl would have reported a false positive at
> In file included from C:/lo-clang/core/vcl/source/window/builder.cxx:74:
> C:/lo-clang/core/vcl/inc\jsdialog/jsdialogbuilder.hxx(176,26): error: unused parameter 'sTypeOfJSON' [loplugin:unusedvariablecheck]
> std::string sTypeOfJSON)
> ^
Change-Id: I14420cf6712a6a18e0d341a5b00e38dff5f6c92e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107330
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/
Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows-
specific unowinreg.dll in generated jars (so that those jars, when distributed
to a Windows environment, would find a LO installation by inspecting the Windows
registry). That unowinreg.dll was originally built as a 32-bit DLL (though when
building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For
non-Windows LO builds, it could either be built locally with a MinGW toolchain
(--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org.
However, that had various issues:
For one, unowinreg.dll was not necessarily available in a distributed jar as a
64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a
jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have
worked. But practically, those URE jars in turn require native DLLs, which
would then not have been available as 32-bit DLLs for use in the 32-bit JRE.)
For another, at least the unowinreg.dll resulting from --enable-build-unowinreg
on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would
generally not have been available in a target Windows environment.
There appears to be no pure Java way to read the Windows registry, but instead
of using a native code DLL for that, it appears to work just as well to call out
to reg.exe and parse its output.
This removes the --enable-build-unowinreg and --with-mingw-cross-compiler
configuration options. (The sole use of the MinGW toolchain in LO was for
building unowinreg.dll.)
Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
