| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I519cdb9b5a1c475a1d36293b77c85c250baf3c3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169520
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(<https://github.com/llvm/llvm-project/commit/397f2e9ebee8d8e45547e90dd05228d7f965df67>)
Change-Id: I51acda5951f8250d1a1b47e1c2612199ae7338a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152618
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...with recent Clang 17 trunk after
<https://github.com/llvm/llvm-project/commit/125f4457a54a550846732763ee36b1447ec8d66e>
"[clang] Remove clang::Optional"
Change-Id: If33406604a614a65dd17e269a0a5c167ea263328
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146347
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as discussed in the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html>
"Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at
<https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html>
"Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up
compilerplugins/clang/ accordingly
Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989
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>
|
|
(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>
|
|
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "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>
|
|
0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also
for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator ==
overloads, but they never got called because the existing 'sal_Unicode const *'
overloads always won.
(The other function overloads introduced with
0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not
have any 'sal_Unicode const *' overload counterparts.)
Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant
fallout. For one, those plugins look at the actual ctor overloads being used,
so had missed those cases that accidentally had used an unexpected overload.
And for another, the heuristic the plugins used to detect the
ConstCharArrayDetector overloads turned out to be too simplistic now and would
have started to cause false positives.
Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...by addressing the follow-up TODO mentioned in the commit message of
7a3736f908c0ae207567603c61ce0f617339bac0 "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>
|
|
Change-Id: I9fbb2e38632d8baa48fb9325824fd2bf7a064d10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95840
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
When building the plugins with NDEBUG defined.
Change-Id: If84a920d9e042bf8f45d8e3dd5a5cef3b2baba0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95788
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Quoting compilerplugins/clang/elidestringvar.cxx (and see there for a
rationale): "Find cases where a variable of a string type (at least for now,
only OUString) is initialized with a literal value (incl. as an empty string)
and used only once."
(This commit includes fixes that become necessary in code changed after the
preceding "Upcoming loplugin:elidestringvar" commits.)
As a follow-up TODO, uses of the
explicit OUString( sal_Unicode value )
ctor where value is char or char16_t literal should be detected too, so that
e.g. one_quote would have been treated like two_quote in
4b85108773f9851f358a4daa8869eeadc638d103 "Upcoming loplugin:elidestringvar: sc"
> --- a/sc/source/core/tool/compiler.cxx
> +++ b/sc/source/core/tool/compiler.cxx
> @@ -1902,9 +1902,8 @@ void ScCompiler::CheckTabQuotes( OUString& rString,
> if( bNeedsQuote )
> {
> const OUString one_quote('\'');
> - const OUString two_quote("''");
> // escape embedded quotes
> - rString = rString.replaceAll( one_quote, two_quote );
> + rString = rString.replaceAll( one_quote, "''" );
> }
> break;
> }
Change-Id: I7b74f1735a07540e3d789df1d14c84081c824b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
