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>
...partially reverting 4fbd63860500b2db76df4d5aedbe5e3aa31fac69 "switching long
to a 64-bit type on 64-bit windows"
Change-Id: I858630e5de76942a001ba619085ee07183df6ff6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104994
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>
...see a9266c39cc71c6f23bfcad4ff6d33ccac53b5e52 "loplugin:toolslong
(--enable-online-update)" arguing that "the third argument to
curl_easy_getinfo(..., CURLINFO_RESPONSE_CODE, ...)
must be a pointer to long".
Change-Id: I7c542595219d2387cf869953fe40faef2b41b44f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104857
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<https://lists.freedesktop.org/archives/libreoffice/2020-October/086169.html>
"Re: Is Executable_libtest still useful?":
>> so I wonder whether that program is actually still maintained and used by
>> anybody. (At least the last dozen or so changes to smoketest/libtest.cxx
>> were of the generic loplugin/typos/tools::Long etc. kind, and we could spare
>> ourselves future such work if we removed the file should it indeed be dead
>> code.)
>
> I think this can be removed. https://gitlab.com/ojwb/lloconv does the
> same and it seems to be maintained.
Change-Id: I039e161ecf4904210e246e389cf4ba85124a66fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104803
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...but where
> ~/lo/core/extensions/source/update/check/download.cxx:297:17: error: VarDecl, use "tools::Long" instead of 'long' [loplugin:toolslong]
> long nError;
> ^~~~~~~~~~~
> ~/lo/core/extensions/source/update/check/download.cxx:153:9: error: VarDecl, use "tools::Long" instead of 'long' [loplugin:toolslong]
> long nCode;
> ^~~~~~~~~~
were false positives (the third argument to
curl_easy_getinfo(..., CURLINFO_RESPONSE_CODE, ...)
must be a pointer to long).
Change-Id: I9596ff32c32fddc7c1240d7fec3672d36265631a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104794
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
...following up on b6d0ca04581eae01817aac18d32a312bc9a2d514 "The Clang
RecursiveASTVisitor change is already in Clang 11"; no longer sure why I
originally wrote the checks using <= rather than < in
5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk
RecursiveASTVisitor change"
Change-Id: I79877e21823334c939ecdf9c64e4efe5e0b1571b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104349
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...see 5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk
RecursiveASTVisitor change"; no longer sure why I thought <https://github.com/
llvm/llvm-project/commit/5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a
RecursiveASTVisitor feature to visit operator kinds with different methods"
would not be included in the release/11.x branch
Change-Id: I1e206368c447b74cc6adec4c1d4790c80f0cb744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104309
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
do more like
commit 121771e37f7e2de41cd5643475861062bf25627b
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...as was suggested by Mike Kaganski in a comment at
<https://gerrit.libreoffice.org/c/core/+/102222/10#
message-aa8bcf42f04686766440e2848c7d1f76f474f2f8> "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString". Doing so revealed that at least
lopglugin:unusedmember needs to handle InjectedClassNameType as an alternative
to RecordType in at least one place. (More places across compilerplugins might
benefit from handling InjectedClassNameType too, but which did not lead to
assertion failures for now and should be addressed in follow-up issues.)
Change-Id: Icdb8b069324b5ce5f3c7c6b92989379ccb67fc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103125
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
note: "pushed" status listener case dropped. Doesn't seem to be an expectation
for it to something in infobars, and there doesn't seem to be a working case
anyway.
Change-Id: I7869cc05de9918f0dd70e28b0087205db6c9506c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101945
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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 998308c363dfad03143591aa18256d2669b4da11
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 e6dfaf9f44f9939abc338c83b3024108431d0f69 "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 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>
to find any global variable, was checking the wrong property of
VarDecl
Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Skia runs internal checks, which occassionally actually may take
a bit. Also abort() in dbgutil build already in case the watchdog
disables Skia, to make finding these easier.
Change-Id: I9ed09c57414e056de20a561b6945cba930edd37b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102096
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...as some members like
OUString::operator std::u16string_view()
don't have a name
Change-Id: I3ac9bbc43cdf899d4ab0483a95f00097f4b6f20a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which disappeared, apparently by accident with...
commit 56e1133f724896aec3f5b5c409fb5917a3b13eb4
Date: Sun Dec 8 19:33:42 2013 -0200
Convert chart 3D scene illumination to .ui
and then a bunch of cleanups removed the unused code
Change-Id: I53fe4f6878dda4f7b8d76a04213b5c6d1366a165
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101917
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...so compat::getSubExprAsWritten is now only needed for the ConstantExpr issue
that cannot hit for LLVM < 8 (see TODO "Turn OStringLiteral into a consteval'ed,
static-refcound rtl_String")
Change-Id: I12ad4624d353b1d801136e9988b261290e2f94d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101905
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>
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>
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>
