...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<61cdaf66fe>
"[ADT] Remove APInt/APSInt toString() std::string variants".
TODO: While most uses of compat::toString should be harmless performance-wise,
as they are either in error reporting code or in plugins that are not run by
default, some calls like the one in compilerplugins/clang/staticconstfield.cxx
might benefit from moving them away from using std::string.
Change-Id: Icfac7d6d4a0a4a4edeb5c8bdcdbc13b73e20a5e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117152
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>
0c8fa58a2d "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
0c8fa58a2d 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>
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office
internal macro for now", so take the liberty of removing it, even if technically
that can be considered an incompatible API change.
Change-Id: I7580a932e1da54845934378a650e894f3f3a9062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...like the one manually found at 06845c14a1 "This
should have become a UTF-16 string literal". (No further misuses were found
across the code base.)
Change-Id: I0b604bdaaa38bd9248440ff7bd7bf0545fc6426a
Reviewed-on: https://gerrit.libreoffice.org/81250
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These are triggered when using llvm-config --cxxflags for building,
and sometimes there's -Werror. The warnings were mostly unused
variables because of being used only in assert(), or default case
in switch that covers all enums (it's better to not handle default
to get warning if a case is not handled).
Change-Id: I0ecdd1f27390aadf033852b0d1ee0ca424ae3c37
Reviewed-on: https://gerrit.libreoffice.org/80317
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Revert part of
commit dd8d5e5795
Date: Mon Apr 29 11:18:21 2019 +0200
improve loplugin:stringconstant
sberg's original gerrit comment:
but there can also be other problematic overloads for parameters like
`void const *` or `std::string_view`. I'm not sure this change is worth
the potential false positives.
and continuing IRC discussion:
<noelgrandin> I'll revert the compilerplugins/ part
<sberg> noelgrandin, my main concern is that /if/ somebody eventually
runs into such an overload situation, it's really hard to get the
warnings/errors fixed for those people, short of going into the plugin
itself
Change-Id: I4916ce8943c4319d7ef9084e22d6a0eeb430b15c
and tweak the methods in check.hxx to make them more flexible when
called with
dc.Class(xxx ? "foo" : "bar")
Change-Id: I881fe628f22121ced4d8849715d6b1c92b092da1
Reviewed-on: https://gerrit.libreoffice.org/64207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
by checking if the current namespace decl is in our code, so we have to
scan less stuff, which results in a 10% perf improvement for me
Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387
Reviewed-on: https://gerrit.libreoffice.org/58942
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which first added alternative names to and then deprecated getLocBegin/End
Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2
Reviewed-on: https://gerrit.libreoffice.org/58820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There are some problems here, this should fix one of them: the
getFilename function returns "<stdin>" for spelling locations, because
the input to clang is sort of preprocessed via -frewrite-includes if
icecream is used and the file is built on a remote host (whereas it's
apparently not preprocessed if the file is compiled locally by icecream).
Using getPresumedLoc() uses the #line directives in the preprocessed
input, which avoids the problem but is more expensive, so try to use it
only when necessary.
The getFileEntry(getMainFileID())->getName() pattern will also result
in "<stdin>", but fortunately icecream passes -main-file-name,
which oddly enough isn't used by the SourceManager's spelling locations,
but is available separately via CodeGenOptions.
This builds everything successfully with clang version 6.0.0:
ICECC_PREFERRED_HOST=myremote make check gb_SUPPRESS_TESTS=t
Change-Id: Ic121511683e5302d7b9d85186c8b9c4a5443fa1b
Reviewed-on: https://gerrit.libreoffice.org/54993
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
