...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 aab0322580 "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 b1617acde1
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 63a68064bb
"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>
(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>
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>
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>
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>
<https://github.com/llvm/llvm-project/commit/
e7f3e2103cdb567dda4fd52f81bf4bc07179f5a8> "Suppress printing template arguments
that match default template arguments of types by default" caused
> error: 'error' diagnostics seen but not expected:
> File /home/sbergman/lo/core/compilerplugins/clang/test/makeshared.cxx Line 58: rather use make_shared than constructing from 'typename std::remove_reference<unique_ptr<int> &>::type' (aka 'std::unique_ptr<int>') [loplugin:makeshared]
> File /home/sbergman/lo/core/compilerplugins/clang/test/makeshared.cxx Line 60: rather use make_shared than constructing from 'typename std::remove_reference<unique_ptr<int> &>::type' (aka 'std::unique_ptr<int>') [loplugin:makeshared]
in compilerplugins/clang/test/makeshared.cxx, and <https://github.com/llvm/
llvm-project/commit/5f12f4ff9078455cad9d4806da01f570553a5bf9> "Suppress printing
of inline namespace names in diagnostics by default, except where they are
necessary to disambiguate the target" caused
> error: 'note' diagnostics seen but not expected:
> File /home/sbergman/lo/core/compilerplugins/clang/test/external.cxx Line 133: a function associating 'N::E' is declared here [loplugin:external]
> File /home/sbergman/lo/core/compilerplugins/clang/test/external.cxx Line 140: a function associating 'N::E' is declared here [loplugin:external]
> File /home/sbergman/lo/core/compilerplugins/clang/test/external.cxx Line 144: a function associating 'N::E' is declared here [loplugin:external]
> File /home/sbergman/lo/core/compilerplugins/clang/test/external.cxx Line 167: a function associating 'N::E' is declared here [loplugin:external]
> File /home/sbergman/lo/core/compilerplugins/clang/test/external.cxx Line 172: a function associating 'N::E' is declared here [loplugin:external]
Change-Id: If1ec798fd9876b5be058c63bcaca3e2a36c0dbb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
add check for passing XML_TOK* constants to a non-sal_uInt16 parameter,
which is a sign of an incomplete fastparser conversion.
Change-Id: Icad5bf9eb40fc15fd07b0d9ea79f83ed083de784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105638
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to find places where the slowparser -> fastparser conversion
work is incomplete, fixing one bug in the process.
Change-Id: Ifd0d801d71eee0aaf25287fbac1a4237a811e7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105511
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so I can convert even *ImportContext subclasses in the middle of
a context stack, and thus break the cyclic dependency nature
of the writer import.
and adjust the xmlimport loplugin for the new rules.
As a consequence of the loplugin:xmlimport's checking, we remove
a bunch of now unnecessary overrides of startFastElement.
Change-Id: I97464522ede8ec5e345e928cdafa4b18364b1b80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar]
> aXmlWriter.content(sPdfConformance);
> ^~~~~~~~~~~~~~~
> ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar]
> OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B";
> ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)
Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For one, the addressOfSet filtering was only done for member functions, not for
free functions, which caused false positives in the wild like the one discussed
in the comments at <https://gerrit.libreoffice.org/c/core/+/102024/
4#message-36ec6ee09ed5badae93c552b82a90068e65d19e2> "call xDesktop->terminate()
when catching SIGTERM/SIGINT" regarding a free function
`terminationHandlerFunction` passed to `osl_createThread`.
For another, it failed to identify some cases where the address of a function is
taken implicitly, like for `f3` in compilerplugins/clang/test/salcall.cxx. So
make this plugin reuse the existing `loplugin::FunctionAddress` functionality
(which also meant to get rid of this plugin's two-phase design).
Change-Id: Ie290c63b03825d5288d982bc8701cfb886fc84b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104585
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
add a check for classes which have been partly converted to fastparser,
but not completedly.
This is to help me when I convert stuff.
and it uncovers a bug introduced with
commit 998308c363
use more FastParser in SvXMLStylesContext
Change-Id: Ib50e7136da10a1a7a346102aa47efef2f543e2ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102669
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to e6dfaf9f44 "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString". (The original code would have
started to fail with
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/unusedvarsglobal.cxx Line 22: declaration of variable 'literal1' with deduced type 'const OUStringLiteral' requires an initializer
when built with Clang >= 11.)
Change-Id: If51a39c8fb42200f064d62f472e8cddcc6e4c434
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102898
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a containers that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral ctor code would probably not be very efficient if it were
ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_view even for such cases, as it should not need any
relocations at library load time. For now, no existing uses of OUStringLiteral
have been changed to some other abstraction (unless technically necessary as
discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::Concat (and which is arguably a better choice, anyway),
also caused failures with at least Clang 5.0.2 (but would not have caused
failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that
have meanwhile been fixed).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
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>
For one, do not warn about global declarations in included files, as generally
not all uses of the variable are seen to decided whether it would be good to
replace. That covers cases like
> In file included from dtrans/source/win32/dtobj/DataFmtTransl.cxx:26:
> dtrans/source/win32/dtobj/MimeAttrib.hxx(29,16): error: rather declare this using OUStringLiteral/OStringLiteral/char[] [loplugin:stringstatic]
> const OUString CHARSET_UTF16 ("utf-16");
> ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For another, do not warn about variables whose pData member is used. That covers
cases like
> sal/osl/w32/procimpl.cxx(347,20): error: rather declare this using OUStringLiteral/OStringLiteral/char[] [loplugin:stringstatic]
> const OUString ENV_COMSPEC ("COMSPEC");
> ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I75c1048098b63164bdb583695951f73964cb24f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101134
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/makeshared.cxx Line 47: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
> File compilerplugins/clang/test/makeshared.cxx Line 49: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
> File compilerplugins/clang/test/makeshared.cxx Line 53: rather use make_shared than constructing from 'unique_ptr<int>' [loplugin:makeshared]
Change-Id: I5d2d1b129c9d0fee496eceb4e2cf14f5853ba00b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100074
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that now defines the wide-character-to-narrow-stream inserters as deleted
too, at least in C++20 mode.
Change-Id: I554f2530d5905e46343bf0d8bf12a6feb3d63075
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100073
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<https://github.com/llvm/llvm-project/commit/
5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature
to visit operator kinds with different methods".
That change is incompatible in that before the change individual TraverseUnary*
and TraverseBin* functions were called, while now TraverseUnaryOperator and
TraverseBinaryOperator/TraverseCompoundAssignOperator are called for all the
different operators. Fixed that with a few #if for the non-shared plugins, but
that doesn't work for the shared plugin. So made the two affected plugins non-
shared for now and left a better fix as a TODO.
Change-Id: I5b87d329ae2c4c93bf605bb1ecc9641039f014a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so drop the former. But keep the relevant externvar tests by moving them
into compilerplugins/clang/test/external.cxx. (Which revealed one difference
between the two plugins, regarding certain extern "C" variables in unnamed
namespaces, where Clang (and for that matter also e.g. GCC, it appears)
deliberately deviates from the Standard and considers them to have external
linkage. Add clarifying comments that loplugin:external keeps considering these
as having internal linkage, following the Standard.)
Change-Id: I344fcd0135fdaf6bf08a4b396af2ed2299389a7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97639
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by addressing the follow-up TODO mentioned in the commit message of
7a3736f908 "New loplugin:elidestringvar"
(extending it not only to uses with a constant sal_Unicode, but also to uses
with OUStringLiteral).
(All necessary changes have been made in preceding "Upcoming improved
loplugin:elidestringvar" commits.)
Change-Id: Ib0000ef9c4a1dad52124dfd039dd936cf7e3ba3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97226
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/unusedfields.cxx Line 143: variable 'x' is uninitialized when passed as a const reference argument here
and
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/writeonlyvars.cxx Line 93: variable 'm_bar10' is uninitialized when passed as a const reference argument here
since <https://github.com/llvm/llvm-project/commit/
170b6869b563dd3393d99f3e03d389b9058d5f24> " [Clang] Add a new warning to warn
when passing uninitialized variables as const reference parameters to a
function"
Change-Id: I27136e387f7a14fd24a3639187b668d6ed283070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95994
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
