summaryrefslogtreecommitdiff
path: root/ucb
AgeCommit message (Collapse)Author
2021-02-15loplugin:referencecasting in ucbNoel
Change-Id: I7531ea30e8d141dce1d1bc27ffbca3fcf28d0ef5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110892 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-11loplugin:refcounting generalise type checkingNoel
Change-Id: Ia013878ac9c2918d8eaf9aab16b291d8211e708f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-09loplugin:referencecasting check for Reference::queryNoel
Change-Id: I008d16d933c70df132699872ac4c39a5c1f87b34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110592 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-08tdf#124176: Use pragma once instead of include guardsShobhit
Applied clang format Change-Id: Idb3f4dc8726115f8d53721bea28cbe3e53adef3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110188 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-02-07Remove unneeded breaksAndrea Gelmini
Extending this: https://gerrit.libreoffice.org/c/core/+/110512 Change-Id: I9e7cf757a346d603d0acb818be0c9bc488c8d5c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110516 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-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-01-28simplify code, use more subView()Noel
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-04loplugin:stringviewparam: operator +=Stephan Bergmann
Change-Id: I30ce1b5bd8fb168da7067c1967c5af2569df2653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108512 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-27Simplify loplugin:stringviewparam comparison operator handlingStephan Bergmann
In practice, it works fine to look at all of them, regardless of actual argument types. Change-Id: Ifc49cbcd6003c8837c1b3f81d432c59fb0657bf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-25ucp: fix call to getComponentContextAndrew Udvare
Commit 3f9940c2e050830051a31e4b70736132e034a9db mistakenly removed include/ucbhelper/getcomponentcontext.hxx seeing the getComponentContext method as unused. According to that file, ucbhelper::getComponentContext was just a duplicate of comphelper::getComponentContext so this commit changes to calling that method instead. Change-Id: Ibd66b56a72afce437a26417d7944ec1ace34a4eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108262 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-14tdf#115643 make onedrive work again by switching to graph APIChristian Lohmaier
the live SDK method had been deprecated quite a while ago and has been turned off a while back. Notes: While you can access and save existing files using the remote files dialog, creating new files or using "save as" requires using the LibreOffice open/save dialogs. Authentication is clunky: username and password you're asked when creating a new connection is not used at all for connecting, so only fill out a username to label your onedrive entry. Actual authentication is done in browser - copy'n'paste the URL from the dialog into the browser, login and approve access for LibreOffice (approving access only necessary once), then you get redirected to localhost, ignore that there is nothing to display. The important part is the code from the URL-bar. Copy and paste that into the LibreOffice dialog and LO can request an authentication token for API access. Testing this feature requires compiling with corresponding api-keys specified in configure/having an app registered with microsoft. Change-Id: I2db11ac09f9fdc354a10d6c749b2bec84b5d34a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107646 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-06Avoid relying on OString(char const *) ctor's undocumented behaviorStephan Bergmann
...of treating nullptr like an empty string Change-Id: I41b8b88f27ed3d3c404781f897952b7d1e0e01e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107279 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-30loplugin:stringviewparam include comparisons with string literalsNoel
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-18tdf#123936 Formatting files in module ucb with clang-formatPhilipp Hofer
Change-Id: I645c81c1454d3eeea6083387f1d343985b4b6d96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105722 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-15Extend loplugin:stringviewparen: subViewStephan Bergmann
Change-Id: Iee4833b148a5e17e09f84bdfbc8692aa5a956618 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105777 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-10-29Revert questionable tools::Long in commented-out codeStephan Bergmann
If it were not commented out, it should presumably stay `long` for similar reasons as the corresponding 13c0326d237cb4860b121ceba8ecb04fe96ae479 "ne_lock::timeout is of type long, so keep using that here" in ucb/source/ucp/webdav-neon/NeonSession.cxx. Change-Id: I2fee057887b6aaceab158edb6b09cc514249061f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105014 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-29SortedResultSet uses sal_IntPtr instead of longStephan Bergmann
...(which had now been changed to tools::Long with 4fbd63860500b2db76df4d5aedbe5e3aa31fac69 "switching long to a 64-bit type on 64-bit windows") since 9eb4e4dc51a4448d59ee80f39144387c7b3cffaf "Some more modules at least building with mingw64" Change-Id: Iea4a68452f22a3c1d4515294e7dab5148e80da05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105009 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-29ne_lock::timeout is of type long, so keep using that hereStephan Bergmann
...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>
2020-10-29libcmis::Property::getLongs returns std::vector<long>Stephan Bergmann
...so that needs to be used here. Reverting part of 7a09d67e1c76db7cb6a87a2ceaa6de7325342b75 "convert some more long -> tools::Long". Change-Id: I73be5bcc5db244012a9cfbc834e85665ba9cfc10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104993 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-29Fix some confusion between UNOIDL long (i.e., sal_Int32) and C++ longStephan Bergmann
...dating back to before d3329bacd8a925ec070ad06ea3d9a6a026a3696b "Moved here from module 'chaos'", in the meantime hit by 4fbd63860500b2db76df4d5aedbe5e3aa31fac69 "switching long to a 64-bit type on 64-bit windows" Change-Id: I378379abf520ce914f1ba2789d788ab726038c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104992 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-28convert some more long -> tools::LongNoel
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) 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>
2020-10-05Removed duplicated includeAndrea Gelmini
Change-Id: Ib3fb174f390424f765113a7565a8b87dbede7342 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103938 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2020-10-04use more TOOLS_WARN_EXCEPTIONMike Kaganski
Change-Id: I269f88d82680f6a969a8bf582f0ae00cc7636509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103925 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-04loplugin:reducevarscope in toolkit..unotoolsNoel
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02Use the new single-instance="true" attribute in ucbStephan Bergmann
Change-Id: I7eb38f0da1d88fd0f7ca4a1054546617b10a3502 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103843 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-01Use the new single-instance="true" attribute in ucbStephan Bergmann
It looks like 3d44c6a49b20415616dab7a2de2820da5efab309 "ucb/core: create instances with uno constructors" mixed up com.sun.star.comp.ucb.UcbPropertiesManager (which had originally been implemented with the single-instance cppu::createOneInstanceFactory) and com.sun.star.comp.ucb.SimpleFileAccess (which had originally been implemented with the multi-instance cppu::createSingleFactory), using a static g_Instance in the C++ constructor function of the former but adding a fake <singleton> to the *.component <implementation> of the latter. Change-Id: Ida7cb242a73fbe7689094e239ffe0c0291cf1d3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103738 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-27Remove unused include list in ucb/cmis_contentJulien Nabet
Change-Id: I7c554e883691e2f97e2f48b2a0353dfa9d4d84d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103507 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-01Fix typo in codeAndrea Gelmini
It passed "make check" on linux Change-Id: I8322ecf2a4c960524fd45cd63fd991d9fa0a3590 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101796 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Fix typoAndrea Gelmini
Change-Id: I03dc9ad3ad496524efbbb2f1a48f76fb95d1bfc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101781 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-21Fix typosAndrea Gelmini
Change-Id: Iaf1d4aed07d1e6fcfe2392fb65cbd2fa196bcc1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101099 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-16loplugin:unusedmethodsNoel Grandin
Change-Id: I2dd10873be73256a3689233c7b1e37bde8f685ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100820 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-14loplugin:simplifybool moreNoel Grandin
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-11Expand XSERVICEINFO_COMMOM_IMPL macro which is now used only onceJulien Nabet
Change-Id: I32de3f604cbb6863e29c0a63b599920a988c8389 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100463 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-11Heap use-after-freeStephan Bergmann
...as seen during UITest_writer_tests2: > ==2548829==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b0002be9d0 at pc 0x7f42be5ddc7f bp 0x7ffe2d26b090 sp 0x7ffe2d26b088 > READ of size 1 at 0x60b0002be9d0 thread T0 > #0 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:84:9 > #1 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36 > #2 in rtl::Reference<UcbPropertiesManager>::~Reference() at include/rtl/ref.hxx:113:22 > #3 in __run_exit_handlers at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:108:8 > #4 in exit at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:139:3 > #5 in __libc_start_main at /usr/src/debug/glibc-2.31-48-g64246fccaf/csu/../csu/libc-start.c:342:3 > 0x60b0002be9d0 is located 64 bytes inside of 112-byte region [0x60b0002be990,0x60b0002bea00) > freed by thread T0 here: > #0 in free at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 > #1 in rtl_freeMemory at sal/rtl/alloc_global.cxx:51:5 > #2 in cppu::WeakComponentImplHelperBase::operator delete(void*) at include/cppuhelper/compbase_ex.hxx:66:11 > #3 in UcbPropertiesManager::~UcbPropertiesManager() at ucb/source/core/ucbprops.cxx:197:1 > #4 in cppu::OWeakObject::release() at cppuhelper/source/weak.cxx:233:9 > #5 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:86:18 > #6 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36 > #7 in rtl::Reference<UcbPropertiesManager>::clear() at include/rtl/ref.hxx:180:19 > #8 in UcbPropertiesManager::dispose() at ucb/source/core/ucbprops.cxx:205:16 > #9 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:79:13 > #10 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36 > #11 in rtl::Reference<UcbPropertiesManager>::~Reference() at include/rtl/ref.hxx:113:22 > #12 in __run_exit_handlers at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:108:8 The elaborate g_Instance disposal scheme had been introduced with 3d44c6a49b20415616dab7a2de2820da5efab309 "ucb/core: create instances with uno constructors", but it is unclear to me for what reason. Change-Id: I768bc3a8674e0e81cf89adae58e4a67d14509985 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100456 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-09ucb/core: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: Ieabf6d417a482ea7cc17e78a78954687e8894cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98801 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-08 11:07:11 +0000