summaryrefslogtreecommitdiff
path: root/unotools
AgeCommit message (Collapse)Author
2021-02-23loplugin:refcounting in unotoolsNoel
Change-Id: I7c4540a6b2975c590b36332f23d15882a79491a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111376 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-16loplugin:referencecasting in UnoControls..unoxmlNoel
Change-Id: I42f216b6115be693a4e57d70f6cbbf11b62ec185 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110998 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-29Replace rtl::Static with function-local static hereMike Kaganski
Change-Id: Iaba5c16c9f80431a5a9c03b94087e3f0b14fd9d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110132 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-29loplugin:stringviewparam extend to new..Noel
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-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>
2021-01-09fix coverity parse errorsCaolán McNamara
Change-Id: I3a1179947704452e3ffec02be59d0f7bf0b75ab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109017 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
2021-01-01tdf#119367: use Unicode paths on Windows in unotoolsMike Kaganski
Change-Id: I671c42c5dfe5acc8a6dd670694c07ff04f08c3e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108477 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-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-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-08use proper struct for trusted authorsNoel
instead of passing around a Sequence<String>, there is no need to use UNO types here. Change-Id: I1b9a1b6919f830d8ce29139b4362b979a669d505 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107396 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-08remove rest of 'xmlsec05' stuffNoel
which has never been used since creation in commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Mon Sep 18 16:07:07 2000 +0000 initial import Change-Id: I1ead1bee759eb09eb72517d90b42813ad66ea1e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107373 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-07remove SID_BASIC_ENABLED and BasicEnabled optionNoel
which has never been used since creation in commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Mon Sep 18 16:07:07 2000 +0000 initial import Change-Id: I018b1f734c8263167dab3d5c6f98a400666f01d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107047 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-04update pchesCaolán McNamara
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-03convert EHistoryType to scoped enumNoel
Change-Id: I115fc0ed81d6392d3649757727c4d9468213619d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-03convert SvtPathOptions::Paths to scoped enumNoel
Change-Id: I2e6cab798309a1bc2ade00661bc95dd5ae20f748 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107045 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-02simplify SvtDynamicMenuOptionsNoel Grandin
just use the struct instead of passing around sequence of sequence of PropertyValue Change-Id: Ic03c066962a10daac6f83f30413a5ab09e1bfd5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106915 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-17loplugin:stringviewparam check methods tooNoel
not just functions Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-03ucbGet needs a non-null interaction handler after allStephan Bergmann
In db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL to download https files", I had not further investigated why using the (GUI) interaction handler within utl::UcbStreamHelper::CreateStream would lead to deadlock during UITest_sw_options (UITEST_TEST_NAME=optionsDialog.optionsDialog.test_moreIconsDialog). Instead, I had passed a null XInteractionHandler into utl::UcbStreamHelper::CreateStream, assuming that would solve whatever the issue was (and it did make the UITest pass). However, that caused the AdditionsDialog to not be populated at all, with > warn:cui.dialogs:26878:26950:cui/source/dialogs/AdditionsDialog.cxx:95: Reading <https://yusufketen.com/api/Templates.json> failed with 0x20d(Error Area:Io Class:General Code:13) (see comment at <https://bugs.documentfoundation.org/show_bug.cgi?id=137922#c1> "Extensions button in Template choose does not show anything"), because interaction requests like com.sun.star.ucb.CertificateValidationRequest were not handled properly. As it turns out, the real reason for the deadlock was that the UITest quickly closes the dialog, causing the main thread to block at m_pSearchThread->join(); in ~AdditionsDialog waiting for the SearchAndParseThread to finish, while SearchAndParseThread::execute encountered a CertificateValidationRequest that needs to be handled and thus blocks in UUIInteractionHelper::handleRequest (uui/source/iahndl.cxx) waiting for the main thread to process the PostUserEvent. In an ideal world, the UCB would allow to cancel the download request issued from ucbGet while that download is waiting for the CertificateValidationRequest to be handled, and the AdditionsDialog CloseButtonHdl would initiate such cancellation. Lacking that, just keep the Close button disabled until the SearchAndParseThread has finished downloading. (Pressing the Close button earlier, ~AdditionsDialog would have blocked the main thread anyway until SearchAndParseThread had finished downloading, so this should not actually worsen the user experience. And the UITest now blocks waiting for the Close button to become enabled before pressing it; there would already be UITest.wait_until_property_is_updated available, but it has a hard-coded timeout which might or might not be relevant in existing uses of that function, so leave it alone and repeat the relevant code without an unhelpful timeout here.) This means that the additional utl::UcbStreamHelper::CreateStream overload introduced in db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL to download https files" is not necessary after all, so remove it again. Two further items that should be looked into: * Should ucbGet pass the AdditionsDialog into utl::UcbStreamHelper::CreateStream as css::uno::Reference<css::awt::XWindow> xParentWin argument (which defaults to null)? * There might be similar deadlock issues involving ucbDownload, which can also be called (indirectly) from SearchAndParseThread::execute. Change-Id: I8d549066940fa4f259a814a31ec7c62960e0db8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105169 Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-10-28Use UCB instead of cURL to download https filesStephan Bergmann
Since 7dc6fc32eb618da6defb8a9f330978fa019677b8 "uitest: Check the more icons dialog opens" started to test the AdditionsDialog code, some ASan builds started to report use-after-poison from within SearchAndParseThread::execute -> curlGet -> curl_easy_perform -> ... -> https_connecting -> ... -> secmod_ModuleInit -> pemC_Initialize -> ..., see the comments starting at <https://gerrit.libreoffice.org/c/core/+/98226/ 10#message-2a55980ab2477e41dc7515e4aeabc7234afc2053> "tdf#133026: Tight integration of extensions - Adding thread structure". The exact cause for that ASan use-after-poison is not quite clear to me. First, I thought it was due to liberal use of curl_easy_init (without a central curl_global_init) in a multi-threaded process; see <https://curl.haxx.se/libcurl/c/curl_easy_init.html> for this being considered "lethal". But then, another issue could be that most of the nss libraries like instdir/program/libnss3.so (implementing the "... -> secmod_ModuleInit" part) come from LO's bundled --without-system-nss while /lib64/libnsspem.so (implementing the "pemC_Initialize -> ..." part) comes from the system, and there could be some mismatch when mixing these (esp. if the former are built with ASan). So whatever the actual cause, the right fix should be to use LO's UCB instead of directly calling into cURL anyway. That required a version of utl::UcbStreamHelper::CreateStream that uses a given XInteractionHandler (which may be null to indicate no interaction handling, instead reporting all interaction requests as exceptions) instead of internally creating an XInteractionHandler using the GUI, and which would cause deadlock in 7dc6fc32eb618da6defb8a9f330978fa019677b8's UITest_sw_options. (And introducing that additional utl::UcbStreamHelper::CreateStream overload required css::awt::XWindow to be a complete type now in vcl/source/graphic/GraphicLoader.cxx, for > include/com/sun/star/uno/Reference.h:277:18: note: in instantiation of variable template specialization 'std::is_base_of_v<com::sun::star::task::XInteractionHandler, com::sun::star::awt::XWindow>' requested here > std::is_base_of_v<interface_type, derived_type> > ^ ) (The removed code in cui/source/dialogs/AdditionsDialog.cxx should have been the last remaining use of curl in Library_cui. Apparently, e1e9e2aa16f08a8fd9e38db706d63e8eceeda8d1 "Kill Mozilla personas" had forgotten to remove it from cui/Library_cui.mk the last time Library_cui had become curl-free, before the introduction of the AdditionsDialog code.) (I did not remove the #undef ABSOLUTE FIXME from cui/source/dialogs/AdditionsDialog.cxx. c4bee547b02fbe3d07b1e9ee203c73e48f86e6bf "tdf#133026: Additions: Better Search Function" does not tell whether it had been added to mitigate a macro definition from the (now removed) #include <curl/curl.h>.) Change-Id: I1fec7488d36df81c3543d12d97da1291f77712fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104938 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-25UNOTOOLS : simplify AccessibleRelationHelper by removing useless impl patternArnaud Versini
Change-Id: I6cb14c5c973067c0ea1c64eab40e38b8b548174f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104776 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-12Changed font order for Korean locale tdf#137392DaeHyun Sung
changed font order priority. 1. put 'Noto Sans KR' ahead of 'Noto Sans CJK KR'. Because, New Noto Sans CJK font change the name. New Noto Sans CJK V2.001 released on 10 Apr 2019. In these font files, removed 'CJK' on names. Nowadays, New Linux distributions includes Noto CJK font V2.0. In Korean Linux environments, Noto CJK font v2.0 'Noto Sans KR' & 'Noto Serif KR' are already set default. 2. fixed Windows fonts for Korean on LibreOffice I watched Windows 10's Korean Font List Microsoft Docs: Font List Windows 10 - Typography; Korean Supplemental Fonts https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts I missed 굴림체;GulimChe, 돋움체;DotumChe, 굴림체;GulimChe. So. I added MS Default Korean fonts. As a result, I changed font order and add default Windows font names. Ref. 1: Google Noto CJK fonts Repository: https://github.com/googlefonts/noto-cjk 2: Microsoft Docs: Font List Windows's Korean supplemental fonts https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts cf.Apple Docs - Format Chinese, Japanese, or Korean text in Pages on Mac https://support.apple.com/guide/pages/format-chinese-japanese-or-korean-text-tanfbd4156e/mac Change-Id: I12594aa8f3122c05810a07a718aae7ec185ba481 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104189 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.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: Id83c478af5d04ad548c7cf4239fe2fb3ee154dc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103861 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-09-25Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I78ef6952782cedead97cf118588f4b7923bb0909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103306 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-24tdf#134782 sw,unotools,officecfg: adapt configuration and UIMichael Stahl
Store AddParaLineSpacingToTableCells in configuration as "AddTableLineSpacing", consistently inconsistent like AddTableSpacing (the <desc> elements are not subject to translation). Adapt SwCompatibilityOptPage with some ugly hacks to allow 3 different states (TriState) for the corresponding checkbox that map to false/false, true/false and true/true. The checkbox widget doesn't allow to change *to* indeterminate but at least the status of the document can be displayed this way, with a non-obvious tweak to optcompatpage.ui to reference "checktri1" column. Change-Id: I5f32e05c93b5e16e782cba5d1d055809d9e5e251 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103318 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 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-07UNOTOOLS : simplify AccessibleStateSetHelper by not using an impl classArnaud Versini
Change-Id: Iae7a028d2845d8b0bef2aefdce2ae00fa7f5660f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102110 Tested-by: Jenkins Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
2020-09-05Simplify creation of the FontNameDictionaryStephan Bergmann
Some of the key sal_Unicode arrays contained embedded NUL characters, for which everything after the first NUL was ignored. But from the corresponding comment, it looks like those sal_Unicode arrays were presumably meant to contain multiple keys that should all map to the same "English name," which I have added now. (The original history of this source file beyond 942dbe34b9a1400c926a81f88e849d248b58ed55 "#i103496#: move some fontsubstitution stuff from vcl to unotools to get xmloff vcl free" appears to be lost, unfortunately. Another comment had already wondered why keys were terminated by double NULs, where the second NUL maybe was originally meant to terminate that sequence of individual keys all stored in a single sal_Unicode array.) There was also another // TODO: check if all dictionary entries are already normalized? in the construction of the FontNameDictionary aDictionary, of which I'm not sure what it should mean exactly, and whether I should have left it in. (This change is a prerequisite for making the OUString ctor taking a raw pointer explicit.) Change-Id: I168778307a67c6b72bf483dc34bfd45f8a48a143 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102086 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03-Werror,-Wcompound-token-split-by-spaceStephan Bergmann
Between <https://github.com/llvm/llvm-project/commit/ 0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace" and <https://github.com/llvm/llvm-project/commit/ 0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove -Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::' and '*' tokens forming pointer to member type are separated by whitespace" warnings, so just clean those places up for good even if the warning would not hit out of the box with any official Clang release. Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-19Fold Bootstrap::Impl::getVersionValue into its single useStephan Bergmann
...thereby fixing that it returns _sDefault instead of an empty string when "version.ini (versionrc) doesn't exist" Change-Id: Ie38afb6d87bd908f8a9773daaf5cee56751ae950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101000 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-19tdf#135133: Don't try to read BuildVersionMike Kaganski
The option to set it was removed in 5fdf2009d21fa220dfee70ea755bd698c16257a7, and now the check is redundant - and even harmful until the remnants of the setting is dropped from bootstrap.ini. Currently the dummy value found there makes the About dialog miss the build id, and copying info to clipboard gives <buildversion> instead of proper build id. Previously the string was always empty in most builds (including TDF), which made the code proceed to buildid. Bootstrap::getBuildVersion got unused now, and is removed. Change-Id: If59e456655da29bb9421edc0e15d421829d0a02b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100957 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-19Drop fallback to read buildid from boostrap ini fileStephan Bergmann
f9e6d8d7c33a308f6f1c15929dd839de2abae3b5 "INTEGRATION: CWS nativefixer18: fix: #124825# read build id from version.ini" from 2005 had left the previous code to read from the bootsrap ini file as a fallback, presumably intended for some (short) transition period. (Plus loplugin:elidestringvar fallout. And fix the comment, which appears to have been non-matching right from the start.) Change-Id: Ia50228f4ae21e9f7ded48fe47d68fcd9931b090c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100967 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-18Fix typosAndrea Gelmini
Change-Id: I85a91d24943430b42217ac91611f182059d8ec69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100919 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-05loplugin:flatten in unotoolsNoel Grandin
Change-Id: I2fad16061bca6dc3e57926863e7a3b71947a8ade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-29replace and drop SvtExtendedSecurityOptions classCaolán McNamara
Change-Id: Ibe3443531c83eb44080217b61f5746be9cce9c49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99695 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29replace and drop MiscCfgCaolán McNamara
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29replace and drop SvtPrintWarningOptionsCaolán McNamara
Change-Id: I17fd4156eb940fbdc925d9761301096e5349135f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99674 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29drop newly unused SvtFontOptionsCaolán McNamara
Change-Id: Iaab664770d96a7d197354949bbe6d82c248f1037 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99648 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-04-27 20:41:30 +0000