summaryrefslogtreecommitdiff
path: root/sal
AgeCommit message (Collapse)Author
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-18Limit nDecPlaces to a sensible value [-20, 20]Eike Rathke
Protect against callers using for example rtl_math_StringFormat_F with rtl_math_DecimalPlaces_Max in worst case.. Change-Id: I9f143df6ae67b22e7732547c0f7a53b498caf2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104472 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-10-12Use `pthread_set_name_np` on FreeBSD 12.1 and below, as `pthread_setname_np` ↵Gleb Popov
isn't available there. While here, change the #ifdef check from __FreeBSD_kernel_ to __FreeBSD__, because pthreads API is userspace (read, belongs to libc). Change-Id: I83e76b5502a6dfa1be5d3598eb1367f25815396e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104098 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-10-08Do not redefine ETIME unconditionally on FreeBSD.Gleb Popov
Change-Id: Iee5e7d3e91b6da5eb6c87d8d3547e0cd65742db7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103945 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-26Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I61781bccc365630f15a9baef5224012b0775edbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103446 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-25cppunittester: [_RUN_____] indicates unit test startJustin Luth
-visual: so that the human eye can easily find it -at start: to identify the last test if it ends abruptly -no spaces: easy scripting | grep RUN | awk '{print $2}' A visually unique, eye-catching start banner will be helpful when browsing through logs, or when adding asserts and running a make sw.check. [I frequently look for existing unit tests that match a certain condition in the 15 ooxmlexport tests.] Previously, the tests ran in the order that they existed in the file. So if one asserted/crashed in the middle of the run, you could easily guess which test it was by finding the name of the test that just finished OK. However, since 2f2246d22e2a8ccbc1dc3e6f5243734a61edf270 Author: Stephan Bergmann on Sat Aug 8 12:00:23 2020 external/cppunit: Run tests in deterministic order the tests are sorted by name and run in alphabetical order - which is not at all obvious or intuitive. It certainly makes it harder to guess what the next alphabetical name will be. P.S. For consistency, I considered adding [____DONE_] as well, but existing tooling might search for "finished in:" and grab the first string (the test name) so I don't want to break anything doing that. Change-Id: I5521e681cd9f8304842290680f0389256fe3fe43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103268 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-23Silence cid#1467434Stephan Bergmann
Change-Id: Ibb996a3440a272405531c6d3cda0faa1d8c72ec2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103260 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-21cppunittester: Do not unload test librariesStephan Bergmann
At least on Windows, e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" caused CppunitTest_sc_tablesheetsobj to fail at exit, when the static OUString aCacheName in ScDocument::GetTable (sc/source/core/data/document.cxx) is destroyed but references constexpr OUStringLiteral gaSrcSheetName(u"SheetToCopy") from test/source/sheet/xspreadsheets2.cxx in Library_subsequenttest, referenced (only) by the CppunitTest_sc_tablesheetsobj library, and both those libraries had already been unloaded from memory. Change-Id: Icea85019611fbaec3603f37b234e9e6fe3502961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103103 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@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-12Replace remaining uses of sal_CharJulien Nabet
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
2020-09-05Make OUString(char16_t const[N]) ctor check for embedded NULsStephan Bergmann
...and fix the detected fallout. That ctor only started to get used recently with a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out that that also gave rise to that ctor being picked in error. To better guard against such erroneous uses, make that ctor assert that the given array does not contain embedded NUL characters, see the new sal/qa/rtl/strings/nonconstarray.cxx tests. The one place where that assert would fire during `make check` is fixed now in SwWW8ImplReader::ImportDopTypography. That assert would also fire for tow OUStringLiteral-related tests in the recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those for how. They cna presumably be added back (with reversed logic values) when OUStringLiteral is changed similarly to how OStringLiteral was changed in 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Change-Id: I6056244003a20f77ba0d953538d25edcbd562211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03Fix typoStephan Bergmann
...introduced with b5ad72bbfca85946e352b56d9d2ee5eb71cd2132 "Replace VALID_CONVERSION macro with function". (VALID_CONVERSION of a lambda was trivially false, as neither OUString nor OUStringBuffer have a ctor taking a lambda, anyway.) Change-Id: I1d4f2de0e1b1973d8680f53e03dbbb3d939fcc03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101982 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann
...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>
2020-08-31Remove some commented-out codeStephan Bergmann
_CRT_NON_CONFORMING_SWPRINTFS is unconditionally defined in solenv/gbuild/platform/com_MSC_defs.mk, anyway Change-Id: I43eabc460dfe3ec9e86ec255f0b100eb22166864 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101696 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann
O[U]StringView had an odd mixture of uses. For one, it was used like std::[u16]string_view, for which directly using the latter std types is clearly the better alternative. For another, it was used in concatenation sequences, when neither of the two leading terms were of our rtl string-related types. For that second use case introduce O[U]String::Concat (as std::[u16]string_view can obviously not be used, those not being one of our rtl string-related types). Also, O[U]StringLiteral is occasionally used for this, but the planned changes outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" commit message will make that no longer work, so O[U]String::Concat will be the preferred solution in such use cases going forward, too. O[U]StringView was also occasionally used to include O[U]StringBuffer values in concatenation sequences, for which a more obvious alternative is to make O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat machinery. Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-29Fix typosAndrea Gelmini
Change-Id: I473956d570feac508e52a3e52cc26cc154f4dc56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101627 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
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>
2020-08-21loplugin:stringstatic (clang-cl)Stephan Bergmann
Change-Id: I024c7437e876459e22a6f541405b87ac13e7dc99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101135 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-17Remove leftover debug includeStephan Bergmann
Change-Id: Idca54798ab5ad464f8a641eb6250cb20aa2147ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100840 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-17loplugin:loopvartoosmallStephan Bergmann
And while at it, merge the change from e2bd5afd726abd5df438b6b821416bd7cf496e4d "Make the C++/UNO bridge work to some extent on macOS on arm64" into the existing code in a better way, reviving the assertion that openMax will be non- negative when entering the loop. Change-Id: I4b4e173a79ae6a0bbbf07df87d46761e86f460c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100841 Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-11loplugin:flattenNoel Grandin
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-10Make the C++/UNO bridge work to some extent on macOS on arm64Tor Lillqvist
Use the same code as for Linux on aarch64, with minor additional hacks. But that will not actually work in all cases, as there are slight differences in the ABI. See https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html Thus we can drop the use of the lo_mobile_throwException() hack that was very temporarily used. The run-time code generation requires use of a new API on macOS to work: See the use of pthread_jit_write_protect_np() in bridges/source/cpp_uno/shared/vtablefactory.cxx. For some reason, with the Xcode 12 betas, when compiling for arm64-apple-macos, the symbols for the type_infos for the UNO exception types (_ZTIN3com3sun4star3uno16RuntimeExceptionE etc) end up as "weak private external" in the object file, as displayed by "nm -f darwin". We try to look them up with dlsym(), but that then fails. So use a gross hack: Introduce separate real variables that point to these typeinfos, and look up and dereference them instead. If this hack ends up needing to be permanent, instead of having a manually edited set of such pointer variables, we should teach codemaker to generate corresponding functions, and look up and invoke them to get the std::type_info pointer. When compiling for x86_64-apple-macos, the type_info symbols end up as "weak external" which is fine. With this, LibreOffice starts and seems to work to some extent, and many unit tests succeed. Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100408 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-04loplugin:elidestringvar (clang-cl)Stephan Bergmann
...plus ensuing loplugin:unnecessaryparen in vcl/source/treelist/transfer.cxx Change-Id: I1abf2e0c589c2c124399c1337f5dd703ee7d04a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100094 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-04Improved loplugin:staticanonymous -> redundantstatic redux, clang-clStephan Bergmann
Change-Id: Ie6dc22edbcfdf05ab8d7d668cb7cc33b5b747995 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100100 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-21Improved oplugin:staticanonymous -> redundantstatic redux, macOSStephan Bergmann
Change-Id: I221351bdc43b48e714acca89bc84db007258299e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99115 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-07Allow making SAL_LOG based output fatalJan-Marek Glogowski
This introduces the [+-]FATAL marker for SAL_LOG. This way you can set part of the matching SAL_LOG string to std::abort on match. The example "SAL_LOG=+FATAL+WARN.vcl.scheduler-FATAL+INFO" will abort for any "+WARN.vcl.scheduler" match, but will just print all additional "+INFO" logs. Change-Id: Ib77f194a78f5165e6c885c82374ae41293815ee9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97651 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: salStephan Bergmann
Change-Id: I022f5ed37d25f2c8a8870033bab32ff59d4d8da6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97648 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-05Upcoming loplugin:elidestringvar: salStephan Bergmann
Change-Id: Ia277fc825d9687fc70d35bc7db92df5cd5d9b2bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95529 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-04Remove useless Result variableStephan Bergmann
It always had a statically known value ever since 9399c662f36c385b0c705eb34e636a9aec450282 "initial import". The always-true check for Result == osl_cond_result_ok in the SAL_INFO invocation was apparently a glitch introduced with a883b6b13b67898accdc1ffe3fd9e770612352b1 "Improve logging". Change-Id: I83ebb3fb02c8f080d560fdff86a98ee5f6a9c204 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95513 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-29loplugin:simplifybool in oox..sdNoel Grandin
Change-Id: I76cbd5d3e65f0b392d713a51607f5c88dae79593 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95101 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-25createSocketImpl is always called with the same argumentStephan Bergmann
Change-Id: I15d442a36407ebfecefe7adf594bffbf1204443e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94796 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-24Revert "Try to blind-solve cppunittester hangs on Windows"Mike Kaganski
This reverts commit 1126515226b60630b3a0fd72c45258b230dfe8fd. Reason for revert: it only took one run after merging the patch to see it still hangs... Change-Id: I9235004d0568462b112da7f23bc615f3647f4755 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94677 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-24Try to blind-solve cppunittester hangs on WindowsMike Kaganski
... calling OleInitialize early in sal_main to initialize COM and concurrency. Seeing intermittent hangs in main thread in CAPNDataObject::GetData calling m_rIDataObjectOrg->GetData, and the inner stack waiting objects in the code doing apartment switching (I forgot to save a stack to paste unfortunately), I suspect that being related to incorrect concurrency model. OleInitialize docs [1] mention: Applications that use the following functionality must call OleInitialize before calling any other function in the COM library: * Clipboard * Drag and Drop * Object linking and embedding (OLE) * In-place activation ... Because OLE operations are not thread-safe, OleInitialize specifies the concurrency model as single-thread apartment. CoInitializeEx sets COINIT_MULTITHREADED by default, so possibly that might get called somewhere before clipboard/OLE code is called. I hope that this change would fix those hangs. [1] https://docs.microsoft.com/en-us/windows/win32/api/ole2/nf-ole2-oleinitialize Change-Id: I7213c9d6cb4bd0691a3ce355995157797d7db93f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94675 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-05-10compact namespace in sal..svgioNoel Grandin
Change-Id: I7e70614ea5a1cb1a1dc0ef8e9fb6fd48e85c3562 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93904 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-29Fix problems when running a sandboxed LO as instdir/.../soffice on macOSTor Lillqvist
The argv[0] passed to osl_setCommandArgs will then be the relative path and osl::realpath() will fail. Instead, use bootstrap_getExecutableFile() which calls _NSGetExecutablePath() to get the executable's pathname for g_command_args. Change-Id: I1345afe158d7b64871f6340733fb5490d5ca6bd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93123 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-17Just use __builtin_ffs on GCC and ClangStephan Bergmann
GCC appears to support it at least since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commit;h=51e2940139d5e3e86590f6e6802ffc3f3010be5b> "Initial revision" in 1992, and Clang appears to support it since <https://github.com/ llvm/llvm-project/commit/d93abc3bb0acdd430839abdd67bd3920fee87bbc> "Implement ffs, parity, and popcount builtins" in Clang 2.4. (And if a build used a compiler that does not support it, there would be no guarantee that it would support strings.h function ffs from X/Open System Interfaces, either.) Introducing HAVE_GCC_BUILTIN_FFS in 334a9f16cd1d1f9694f885c759903a41aa3d4833 "tdf#113211: fix calculations with big integers" appears to be due to a misguided recommendation at <https://gerrit.libreoffice.org/c/core/+/43477/4# message-899806c724fbdcece0ea9438514a6a5db6a2e645>. Change-Id: Ib6ee6de548172b3aae25483d03efb86620133933 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92421 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-15loplugin:buriedassign in salNoel Grandin
Change-Id: I5a7bc9378ceacb9116c03e3a9fc01c5675c40908 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92243 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-06Nah, let's revert that shiteTor Lillqvist
This reverts commit 533f0094df9a591116b73dca63bc34ddab683bdd. This reverts commit 96ae6bc47414194a477bf95a1f5a360b555884b3. This reverts commit 0050759cb9cf8ac337c0ecec48c009501de9fb0f. This reverts commit 70de006670880df7931fb1c39966d181e2893a61.
2020-04-04Let's put some verbosity in #if 0, thoughTor Lillqvist
Change-Id: I862c6277b4ef8d80bd6352fe27fed96a262cd02e
2020-04-04Show what pathname a fd was opened from in the SAL_INFO("sal.file") callsTor Lillqvist
The pathname is logged in abbreviated form. This, like the two preceding commits, is not claimed to be perfect, MT-safe, etc. It is for debugging output, for SAL_LOG=+INFO.sal.file. If you don't like it, don't use it. Or improve it. Or revert it, I promise not to bother again. Just don't start bike-shedding. Change-Id: Ie8fcea5f5f2373671eebf9ee54d32143e7ed68e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91679 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-04Add SAL_INFO with "sal.file" also for the pread, read, pwrite, and write callsTor Lillqvist
Change-Id: Ib8fe62614a87d7350bec195ff22ae5701558d967 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91678 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-04-04Show flags and modes symbolically in the SAL_INFO() for open() and access()Tor Lillqvist
Change-Id: I0d3f7f7216d35bb6f636797894832a4714bcc388 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91677 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-04 05:26:03 +0000