summaryrefslogtreecommitdiff
path: root/sal/qa
AgeCommit message (Collapse)Author
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-02Revert "sb138: #i115619# fix for MinGW"Mike Kaganski
This reverts commit 6727dc5d9414e77975b9fd765993c6e207f872f3. We now don't support compiling using MinGW. Change-Id: I0dee00780bfb4b7deceddd8cd30af03b7f7ed212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116591 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-01fix leak in SocketTestNoel Grandin
Change-Id: I8c5e2d4c4687beab08876fe3e945d19a1629bc36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-31Replace inet_addr with inet_ptonStephan Bergmann
...as inet_addr is deprecated (it does not allow to distinguish successful return for "255.255.255.255" from -1 error return); and update tests Change-Id: I605cb2ba18fe9bd11d2d68c8f1c94271c4503509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116441 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-31Replace inet_ntoa with inet_ntopStephan Bergmann
...as inet_ntoa is potentially not thread-safe; and add a test Change-Id: I9df945b006ba7194c3b1444c4886101c08339ad0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-27loplugin:stringadd (clang-cl)Stephan Bergmann
Change-Id: Id7c2db4abcf947c4efa0296df29feca2c36d3cf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-19use more string_view in OString APINoel Grandin
some parts of the OString seem to have fallen behind its more popular sibling OUString. Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-04Also check number of invocations in the testMike Kaganski
Change-Id: I4180f14aa633bf0f3f45178c1fd02b52b784f7e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111960 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-04Improve unit test accuracyMike Kaganski
I didn't take clock resolution into account when created the test, and it failed for me occasionally because the value was slightly less than expected. The typical system tick resolution is documented at https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Change-Id: Ie48b10d15b14f9ac7d292a2cc9916bcbfff44b6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111946 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-03tdf#116983 tdf#136175: retry if failedMike Kaganski
Debugging the test case from the latter bug report shows that indeed the call to OleGetClipboard may fail first time, as jasonkres had suspected in the former bug. So follow the suggestion in tdf#116983, and retry the failing calls several times in case of failure. Many thanks to Telesto for preparing a clear bug report with reliable test case. Co-authored-by: jasonkres Change-Id: Ib3c497da830bc5faac586bcfe1eededa54bfa117 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111825 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-27Drop ComPtr and use sal::systools::COMReferenceMike Kaganski
Change-Id: I9eb6d99d883b44943ad69c2c28d4e55716dc34f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111673 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-12Make sure to resolve symlinks in temp path in path testsMike Kaganski
This is a blind attempt to fix a part of a failure reported on IRC: /lode/dev/core/sal/qa/osl/file/osl_File.cxx:486: Assertion Test name: osl_FileBase::getAbsoluteFileURL::getAbsoluteFileURL_001_1 equality assertion failed - Expected: file:///var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T//relative/file1 - Actual : file:///private/var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T/relative/file1 - Assumption is wrong: ResultURL is not equal to expected URL That "private/" in Expected might be because user's /var is a symlink to /private/var. Change-Id: Ia5b95621dffdae7e0193aca4c3d12c86ed28dceb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110785 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2021-02-10Fix creation of some OUString from non-ASCII ordinary string literalsStephan Bergmann
On platforms where char is signed, > OUString aTmpName10(aTempDirectoryURL + "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030"); would have created, via addDataLiteral (include/rtl/stringconcat.hxx), an OUString containing sign-extended char16_t counterparts of the \x char values (\xE6 -> \uFFE6, etc.). That caused CppunitTest_sal_osl CPPUNIT_TEST_NAME=osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 under an RTL_TEXTENCODING_ISO_8859_1 locale (e.g., LANG=C, as used by Fedora when executing the %check part of libreoffice.spec) to fail on such signed-char platforms (e.g., Linux x86_64) with > [_RUN_____] osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 > createTestDirectory failed: 21! > sal/qa/osl/file/osl_File.cxx:267:osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 > assertion failed > - Expression: (osl::FileBase::E_None == nError) || (nError == osl::FileBase::E_NOENT) > - In deleteTestDirectory function: remove Directory file:///tmp/?????????zhgb18030 -> result: 21 because FileURLToPath -> osl::detail::convertUrlToPathname -> getSystemPathFromFileUrl<rtl::OString> -> decodeFromUtf8 -> convert (all sal/osl/unx/file_url.cxx) would fail to convert those values beyond \u00FF to RTL_TEXTENCODING_ISO_8859_1, ultimately returning osl_File_E_INVAL (i.e., 21). (We could "fix" addDataLiteral in include/rtl/stringconcat.hxx, explicitly converting from char to char16_t via unsigned char, but arguably that concatenation construct should only be used with ASCII-only ordinary string literals, similar to the restrictions for OUString construction from such string literals.) (Before 5a77636c9a638c86fd3de3afb6e88cf48f987b6a "WIN enable osl_File.cxx part of CppUnitTest_sal_osl", that aTmpName10 was constructed as > OUString aTmpName10(RTL_CONSTASCII_USTRINGPARAM( FILE_PREFIX TEST_PLATFORM TEST_PLATFORM_TEMP "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030" )); but that would have caused similar issues, as RTL_CONSTASCII_USTRINGPARAM uses RTL_TEXTENCODING_ASCII_US which converts non-ASCII chars to RTL_TEXTENCODING_MS_1252 (see comment at aImplUSASCIIByteCvtData, sal/textenc/textenc.cxx), which would have converted e.g. \x9C to \u2018, which then would have failed to be converted to RTL_TEXTENCODING_ISO_8859_1. And that use of RTL_CONSTASCII_USTRINGPARAM had violated the requirements as stated in include/rtl/ustring.h anyway: "Each element of the referenced array must represent an ASCII value in the range 0x00--0x7F.") Whatever this crappy getSystemPathFromFileURL_005 actually wants to prove, it happens to work now also for RTL_TEXTENCODING_ISO_8859_1 locales. Change-Id: I044c4bd3aee4f7ea4f29737b6876cc55e4e6e436 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110714 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-10Be a bit more verbose in that crappy test codeStephan Bergmann
Change-Id: Ic0500db292d52a827f2139cd2cbbc0e8e4274dac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-10Fix loplugin:stringliteralvarStephan Bergmann
...detection of OUString( const sal_Unicode * value, sal_Int32 length ) ctor. (On platforms where sal_Int32 is a typedef for int, an argument that already is of type int will not be wrapped in an ImplicitCastExpr to the sal_Int32 typedef.) Change-Id: Ifc5456a62d42c1acad76ea949549dc24bd67201a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110654 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09loplugin:fakebool followed by loplugin:implicitboolconversion (clang-cl)Stephan Bergmann
Change-Id: I0f61268b2027eb617b2312615ea544387af1b381 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110643 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09report what value was found in messageCaolán McNamara
Change-Id: I512cedcd46f829b97b62a57d90d5a4a81d024d66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110562 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann
...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>
2021-02-05Revert "Fix typo in code"Stephan Bergmann
This reverts commit 3ed9bba283a6a67864c0928186e277240be0d9ba. osl_Pos_Absolut (include/osl/file.h) is part of the stable URE interface; it must not be changed. Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-05osl_File checks: creation in root can also fail because of read-only filesystemChristian Lohmaier
80b7949016fbc6addd54bf9f6cf300c756fd0f8a enabled a bunch of previously disabled checks, but on m1 macs osl_File::open::open_004 fails the assert, because it doesn't fail with E_ACCES, but with E_ROFS. (probably nothing to do with apple silicon, but rather because of Big Sur and using apfs as filesystem) Change-Id: Ibd2168ba5fb9d859ea339713099c9bc8a799fcc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110431 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-02-04Fix typo in codeAndrea Gelmini
Change-Id: Ib8b306a27d25a34e784aeeb72708b0d5d1511f3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110394 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2021-02-03Enable previously disabled file and directory testsMike Kaganski
Change-Id: If94a492fa8ef2167bb4c767802e8ea92405a59e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110337 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-02Do not forget to remove "." and ".." path parts in osl_getAbsoluteFileURLMike Kaganski
A follow-up to commit 6e0fa7d4c7b45c98418c289d1d4715eb9eb133f7. Also enables corresponding unit tests on Windows. Change-Id: I250d1269e06c8ce11ebc0e4ea12171c5755aa42d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110273 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-28add string_view variants of methods to O[U]StringBufferNoel
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27Improve loplugin:stringliteralvarStephan Bergmann
...to also consider O[U]String ctors taking pointer and length Change-Id: Iea5041634bfbf5054a1317701e30b56f72e940fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110025 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-15OUString::matchAsciiL() can be used instead of the fresh startsWithAsciiL()Tor Lillqvist
Revert the addition of the latter. Change-Id: I93636a901cde401b0b7d923e052887f57dd58212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-14Introduce startsWithAsciiL() to match endsWithAsciiL()Tor Lillqvist
Will be used in an upcoming change. Unit test included. Change-Id: I777a755cab543ea277b84fb5ad021d0b91725764 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109264 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-10fix coverity parse errorsCaolán McNamara
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
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>
2020-12-23Use char16_t string literalsStephan Bergmann
Change-Id: I0a8b577957ac1d4cad5fc1163f244012a8391a77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108216 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-20Remove the OUString vs. std::u16string_view comparison operators againStephan Bergmann
...that were introduced in e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" to avoid ambiguities, but which is no longer an issue since 46c5de832868d2812448b2caace3eeaa9237b9f6 "make *String(string_view) constructors explicit" Change-Id: I0a7a3fe23412f77fa85fb7e90f04e22f9abd9230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108044 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Add empty OUStringBuffer::toString testStephan Bergmann
...motivated by <https://gerrit.libreoffice.org/c/core/+/107643> "Don't crash on an empty OUStringBuffer::toString" Change-Id: I144f0814f585f56df3fcdc818fd8c5e18ad08115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107672 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-10Avoid calling OString ctor with null pointerStephan Bergmann
...in preparation of potential future changes from using OString to using std::string_view, where OString has an undocumented feature of allowing construction from a null pointer. This is mostly the result of a manual audit of potentially problematic getenv calls across the code base. But there can be other problematic places too, like the xmlGetProp call in tools/source/xml/XmlWalker.cxx. To identify those, rtl_{string,uString}_newFromStr aborts now in non-production debug builds when a null pointer is passed(and all places that hit with a full `make check screenshot` have been addressed here). Once we are confident that all problematic places have been identified, we should drop support for the undocumented feature (see the TODO in sal/rtl/strtmpl.cxx). Change-Id: I595cc6d4f1cda74add2a3db171323f817d362b08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107430 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Improve a CPPUNIT_ASSERT messageStephan Bergmann
Change-Id: Ia40f249a115a8c4fe01fb384041b4542735166c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07Revert "Fix osl_Security::getHomeDir test under fakeroot"Stephan Bergmann
This reverts commit c8098382da6a7a0448ff8051cac467f91d7e0b36. Conflicts: sal/qa/osl/security/osl_Security.cxx There should be no good reason to run unit tests like CppunitTest_sal_osl_security under fakeroot, esp. not since a58e086ededb8442938e81f971dfae36ef7eb076 "rework the default make target" no longer runs them as part of a plain `make`. (And getting rid of this code means one less place to audit for nullptr issues with getenv in combination with potential OString -> std::string_view changes.) Change-Id: I6bba0ed28ea1ba894ee182f8bda35aad69a54dc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03tdf#138360: sal_rtl: Add unittestXisco Fauli
Change-Id: Iac6c4bf09f55446128d7fb7a35b483ca41bc4f00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107080 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-11-28Unit tests for DBL_MAX to string conversion, tdf#136272Eike Rathke
Change-Id: Ied41d1e21fb6e40b54adac3c33fa0d096e25bada Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106783 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-21Relax non-null requirement for some rtl_uString_* functionsStephan Bergmann
...that take a pointer and a length, and where it should be OK that the pointer is null if the length is zero. Those rtl_uString_* functions are targets of OUString member functions that take std::[u16]string_view arguments, and 19926ed35ebb623fc896942b1f232b83edf1fc1e "loplugin:stringview: Flag empty string converted to string view" (which changed some call sites to pass in default- constructed std::[u16]string_view, for which data() returns null) revealed that those rtl_uString_* functions were not prepared for such input. (The guardings of memcpy are necessary because memcpy still requires its pointer arguments to be non-null, even if the corresponding length is zero.) The new sal/qa/rtl/strings/test_strings_defaultstringview.cxx systematically tests all O[U]String[Buffer] member functions taking std::[u16]string_view arguments. It revealed one further issue in IMPL_RTL_STRNAME(compare_WithLength), where UBSan reported a nullptr-with-nonzero-offset > sal/rtl/strtmpl.cxx:149:9: runtime error: applying non-zero offset 18446744073709551614 to null pointer Also, rtl_uString_newReplaceFirstUtf16LUtf16L was found to lack a check for its `from` argument to be non-null. Change-Id: I6a7a712570f7d1e8d52097208c8a43a5a24797af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106295 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21tdf#123936 Formatting files in module sal with clang-formatPhilipp Hofer
Change-Id: I04a773e8fd565f57dc0eb887fb4714b6edbb35e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105699 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-11-11loplugin:stringviewNoel
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>
2020-11-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28Extend loplugin:elidestringvar to OStringStephan Bergmann
(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>
2020-10-05loplugin:reducevarscope in salNoel
Change-Id: I2ce95de07b8e0952a1e778e65940b30597396aa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103949 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
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>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...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>
2020-09-08Fix typos in commentsStephan Bergmann
Change-Id: I8a8108ae970613559a68d996dddcee485ddc052f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102235 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-08-11 19:57:13 +0000