summaryrefslogtreecommitdiff
path: root/configmgr
AgeCommit message (Collapse)Author
2023-07-18Make sure that root listeners are notified firstMike Kaganski
The problem appeared when in a configuration listener's changesOccurred, a configuration value was read using officecfg machinery, which could return the old value of the configuration, or an updated one, at random. This was caused by use of a cached value in comphelper::detail::ConfigurationWrapper::getPropertyValue, which is cleaned in ConfigurationChangesListener::changesOccurred; but the order in which the listeners' changesOccurred methods were called depended on the implementation detail of configmgr::Components::roots_, which was previously a std::set of pointers, and now is a sorted vector. This made the pointers sorted in order of the pointers' addresses (basically random), and when a broadcaster's common list of change listeners was prepared in Components::initGlobalBroadcaster, ConfigurationWrapper's listener could arrive last. This meant, that the cache could be cleaned too late, after its obsolete content was already used in a previous listener. The problem could be partially mitigated by clearing the cache in the comphelper::detail::ConfigurationWrapper::setPropertyValue, but that would only handle cases of config modifications using comphelper. Instead, take into account that ConfigurationWrapper listens on the root of configuration tree; and introduce a separate container in configmgr::Broadcaster for root listeners. They would be triggered first, before all other listeners. Still, this would not guarantee the proper order, if another listener is registered on root. To handle all cases, a special listener category could be used, which could be filled using a dedicated internal API, so comphelper could use it to register its privileged listener close to the heart of the broadcaster :) This might be implemented later. Change-Id: I956b7989b3927dca2683f63cf92b0dda04db9bdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154561 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-18Use getXWeak in configmgrMike Kaganski
Change-Id: Ia7d9475cecd2208ccf672f2b35c0c841fed7f4dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150840 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-25merge some stringaddsNoel Grandin
found with a lightly tweaked version of the loplugin:stringadd and some hand-holding. Change-Id: I146aadcaf665e98fea89a9cad2df4dc3935622f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152275 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-24Fix CppunitTest_configmgr_unit for --disable-report-builderStephan Bergmann
...after abd630e81bc150d05e4129cc22752ecf461777c7 "Allow all hierarchical path segments to be ['...'] quoted", which failed as the checked MimeTypeClassIDRelations group is conditional on install:module="reportbuilder". (See the comments at <https://gerrit.libreoffice.org/c/core/+/151673/2#message-f029dd1877f8a946647456ed73a7b60f6dfc0e8f> "Allow all hierarchical path segments to be ['...'] quoted".) It looks like there is no other, non-conditional property with a slash in its name, so the test now just tests the ['...'] syntax on an otherwise unproblematic property name. (Alternatively, we could have extended the configuration data used by unit tests with such a problematicaly named property.) Change-Id: I820004a5b824326d86e67c158994f13e71ba135e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152184 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-11Allow all hierarchical path segments to be ['...'] quotedStephan Bergmann
...and not just set elements. <https://gerrit.libreoffice.org/c/core/+/151660> "tdf#104005 Don't allow changing finalized properties" found that some existing property names include "/", which makes them unusable with e.g. getPropertyByHierarchicalName. The most obvious solution is to allow ['...'] quoting (without a leading template name, though) for all kinds of hierarchical path segments. (In theory, that would cause backwards incompatibility, as e.g. a property named ['foo'] could no longer be referenced by a ['foo'] path segment (it would need to be referenced by a ['[&apos;foo&apos;]'] path segment instead). But in practice, that path segment ['foo'] would have been rejected in the past anyway, as it did not reference a set element.) To make this work, the meaning of the setElement out-parameter of configmgr::Data::parseSegment is changed to only be true if the segment uses ['...'] notation including a leading (non-empty) template name. What this change does not (yet) address is writing out such quoted (group or set) names in the hierarchical paths written out in configmgr::writeModFile, where necessary. (It never writes out names of properties as parts of hierarchical names, so this wouldn't be an issue for the existing problematic properties containing "/" in their names, anyway.) Change-Id: I635d823c7bbb6b8ac5869c7e0130ba8cfd329599 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151673 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-28optimise find/insert calls to mapsNoel Grandin
Instead of doing two lookups, we can just call insert and then update the mapped-to value if the insert actually succeeded. Change-Id: I3df3b98f0debe6bf74c739dd5850e7714d9c2789 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-18Some missing XServiceInfo implementationsStephan Bergmann
Change-Id: I1cf871b40f9f4020147dac0456ebeed3de0438e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150533 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-24loplugin:stringadd in c*Noel Grandin
after my patch to merge the bufferadd loplugin into stringadd Change-Id: I66f4ce2fd87c1e12eefb14406e0e17212f68ceff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149497 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-16tdf#143148: Use pragma once instead of include guardsUday Sharma
Change-Id: I6898acbf7c6c9de45bbfa6a32202acf302f92caa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146822 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-03-15Bump dconf minimum version requirementStephan Bergmann
At least building on Fedora 37 with dconf-devel-0.40.0-7.fc37.x86_64 against recent LLVM 17 trunk libc++ started to fail now with > In file included from configmgr/source/dconf.cxx:25: > In file included from /usr/include/dconf/dconf.h:23: > In file included from /usr/include/dconf/common/dconf-enums.h:23: > In file included from /usr/include/glib-2.0/glib.h:34: > In file included from /usr/include/glib-2.0/glib/gasyncqueue.h:34: > In file included from /usr/include/glib-2.0/glib/gthread.h:34: > In file included from /usr/include/glib-2.0/glib/gatomic.h:30: > In file included from /usr/include/glib-2.0/glib/glib-typeof.h:44: > In file included from ~/llvm/inst/bin/../include/c++/v1/type_traits:430: > ~/llvm/inst/bin/../include/c++/v1/__type_traits/aligned_union.h:23:1: error: templates must have C++ linkage > template <size_t _I0, size_t ..._In> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > configmgr/source/dconf.cxx:19:1: note: extern "C" language linkage specification begins here > extern "C" { > ^ because the missing extern "C" has meanwhile been added to upstream dconf with <https://gitlab.gnome.org/GNOME/dconf/-/commit/f860ddcc6a501b982d82c5630c73936bd611ad8a> "common: Add missing G_BEGIN/END_DECLS" towards tag 0.40.0. So the easiest fix here appears to be to bump our requirements to that dconf version 0.40.0: The one case I'm aware of that explicitly wants dconf support is downstream Fedora and RHEL builds, which already have dconf 0.40.0 (cf. most recent <https://src.fedoraproject.org/rpms/dconf/blob/a9987b0abe15133d091bcd390fd33077881567ae/f/dconf.spec#_4> for f37 and most recent <https://gitlab.com/redhat/centos-stream/rpms/dconf/-/blob/1bb6b46da242b75e5e1864f5c97ab6e592ca60ba/dconf.spec#L4> for e9s). On the other hand, the TDF Linux release builds are done with an explicit --disable-dconf in distro-configs/LibreOfficeLinux.conf (since ecc617e797aa5ed329668114e54ec7ffa5c0e87b "configmgr: support reading from a dconf layer (WIP)") and the Flatpak builds on Flathub are done against an org.freedesktop.Sdk//22.08 where no dconf support is detected at all (for the most recent LO 7.5.1 build on Flathub see > checking for DCONF... no > checking whether to enable dconf... no at <https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio> for aarch64 and at <https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio> for x86_64). Change-Id: I559d2ac8712dbe2b40c9b881314b88d1cc8eaf43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148887 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-23unlock during dispose in configmgr::configuration_provider::ServiceNoel Grandin
Since the code that can run during flushModifications might manage to call back into Service.. regression from commit a61951a3a21c6457334f78f657806c1167dbf339 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Mon Feb 20 20:08:30 2023 +0200 BaseMutex->std::mutex in configmgr::configuration_provider::Service Change-Id: I0070e7589cdea38905de6c68adefd8081b122152 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147500 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-21fix locking in configmgr::configuration_provider::ServiceNoel Grandin
a mistake from commit a61951a3a21c6457334f78f657806c1167dbf339 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Mon Feb 20 20:08:30 2023 +0200 BaseMutex->std::mutex in configmgr::configuration_provider::Service Change-Id: I59c670ea7bffacb9dcd1f073b5da2439c2102a45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147392 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-21BaseMutex->std::mutex in configmgr::configuration_provider::ServiceNoel Grandin
Change-Id: Ie8f7cb4cd91ac0089365a691f07962a26d51a72a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-17Verify that zh-Hant-TW locale works in configmgr as intendedStephan Bergmann
...after b52117c0be97c45824d2897657084f8ac7e9bf42 "Try an override locale as first fallback" Change-Id: I23d8459fff4d76fd9d542d098953bf97cf5397a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147219 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-17Verify that es-419 locale works in configmgr as intendedStephan Bergmann
...after a9b97301ba75a74e6671a6b9829f7044e85db6af "Do not add empty language tag to fallback strings" Change-Id: Ie42929c2ce6331012358f72026ae774b9dd0e369 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-17Try an override locale as first fallbackEike Rathke
Change-Id: I4ca6db43fef2706c4c1bab020e2170f6cf45a441 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147184 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-02-16Do not add empty language tag to fallback stringsEike Rathke
This happened for known tags like es-419 but unhandled in simpleExtract(), which actually should be implemented as now a few are mapped as known tags. Prevent adding such empty string. For that, adjust configmgr/qa/unit/test.cxx to test for the expected "en-US" instead of "default". Change-Id: I05f8e35a9d88b42d45e1f2a90aecec5f4470cc79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147135 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-02-16Improve testLocalizedPropertyStephan Bergmann
c3bd52f81bf733a0b9b0560794a54b2ac1e0f444 "Use the (first segment of the) original locale value for the workaround again" had stated: "The added test code unfortunately doesn't actually test this piece of code, and somewhat unexpectedly receives the "default" value from the empty string locale default, rather than the "en-US" value from the higher precedence "en-US" locale default, because `aFallbacks` happens to contain an empty string, so we already leave Access::getChild early in the 'Find the best match using the LanguageTag fallback mechanism, excluding the original tag' block." But, of course, the relevant code can well be tested after all, using a localized property that does not have a default no-xml:lang value. (And add a TODO comment about the unexpected "default" vs. "en-US" in the original test code, in case the LanguageTag::getFallbackStrings behavior ever changes and the test starts to fail.) Change-Id: I526a830a5929b6b5ad17ba57af5943954b07b86a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147137 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-15Use the (first segment of the) original locale value for the workaround againStephan Bergmann
cf7c9599e776eba8e14614cecb528d3da5778190 "Make comphelper/configuration.hxx work for localized properties", which had originally introduced this code, had been careful to ensure that the > assert( > !locale.isEmpty() && locale.indexOf('-') == -1 && > locale.indexOf('_') == -1); would always hold here (it had already removed all trailing "-..." and "_..." segments, but had made sure to stop before `locale`, which is known to initially be no non-empty, would have become empty, by treating a leading "-" or "_" not as a segment delimiter, but rather as a first segment). dfc28be2487c13be36a90efd778b8d8f179c589d "configmgr: Use a proper LanguageTag-based locale fallback mechanism" had changed that, instead setting `locale` to some value obtained from `LanguageTag::getFallbackStrings`, which might or might not satisfy the assert. But there was no good reason for that part of dfc28be2487c13be36a90efd778b8d8f179c589d in the first place: The workaround (as explained in the leading code comment) was meant to be carried out with the first segment of the original `locale` value, not with some fallback value. So put back here the computation of that first segment of the original `locale` value. (And drop the misleading empty line that dfc28be2487c13be36a90efd778b8d8f179c589d had, for no good reason, introduced between the workaround's leading code comment and its actual code.) However, it turns out that there was one flaw in cf7c9599e776eba8e14614cecb528d3da5778190: When the original `locale` starts with "-" or "_", the resulting `locale` representing the first segment will be "-" or "_", so the `locale.indexOf('-') == -1 && locale.indexOf('_') == -1` part of the assert would be false. But that wouldn't be an issue for the following code (the only issue would be if `locale` had become empty, in which case the `name2.startsWiht(locale)` check would trivially become true, and that for loop would erroneously pick the child with the empty `name2`), and that part of the assert had merely been there to reinforce that `locale` had indeed been stripped down to the first segment. A correct version of the assert would have used `locale.indexOf('-', 1) == -1 && locale.indexOf('_', 1) == -1` instead, but as the code now makes it obvious anyway that `locale` has been cut down here to the first segment, we can just as well simplify the assert to just the `!locale.isEmpty()` part. (The added test code unfortunately doesn't actually test this piece of code, and somewhat unexpectedly receives the "default" value from the empty string locale default, rather than the "en-US" value from the higher precedence "en-US" locale default, because `aFallbacks` happens to contain an empty string, so we already leave Access::getChild early in the "Find the best match using the LanguageTag fallback mechanism, excluding the original tag" block.) Change-Id: Ib92e714c9db4879be058529ec905e631df975424 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147113 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-15Add a rudimentary test for localized propertiesStephan Bergmann
Change-Id: I9abe06e6f1f2b6b39cbbf07043dd9c5062ff0460 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147108 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-15Remove unused configmgr/qa/unit/urebootstrap.iniStephan Bergmann
...left behind by 6a370f580aaf060004536dfc8ca877c9a2114c66 "configmgr: remove unused old dmake file" Change-Id: I9209b672f0b3242f6801935722b3108ef692787a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147096 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-02osl::Mutex->std::mutex in configmgr::read_write_access::ServiceNoel Grandin
Change-Id: Ic8f688d3ad66c1be33a147e05b0e9145593214f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146471 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-02osl::Mutex->std::mutex in configmgr::read_only_access::ServiceNoel Grandin
Change-Id: Ia92bb76cedb45d2c28482d34869e239cfdd32ebf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146470 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-23XUnoTunnel->dynamic_cast in configmgr::ChildAccessNoel Grandin
Change-Id: Iadfdbb68ad7876801bf79352bdec26da7da63325 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145993 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski
And use an overloaded helper function with a better (?) unified name to show that the result is not an O(U)String. Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-09-27Revert some string_view pessimizationStephan Bergmann
This reverts the configmgr part of 0a7eac8576f313dcaf27ee45326d71fd6b5aea1e "use more string_view in accessibility..configmgr": All calls to Data::parseSegment (either directly, or indirectly either via Access::getSubChild or via parseSegment in partial.cxx) pass in an OUString path, and in some cases (see below) > *name = path.substr(index, i - index); in Data::parseSegment reconstructs an OUString from the full path (i.e., index == 0 and i == path.size()). And I see no code that actually benefited from the switch to string_view. One example call stack for such an expensive reconstruction of an OUString from full path is > #0 in configmgr::Data::parseSegment(path=u"ooSetupSystemLocale", index=0, name=0x7ffff5299280, setElement=0x7ffff52992a0, templateName=0x7ffff52992b0) in core/configmgr/source/data.cxx > #1 in configmgr::Access::getSubChild(this=0x619000028f80, path=u"ooSetupSystemLocale") in core/configmgr/source/access.cxx > #2 in configmgr::Access::getByHierarchicalName(this=0x619000028f80, aName="ooSetupSystemLocale") in core/configmgr/source/access.cxx > #3 in utl::ConfigItem::GetProperties(xHierarchyAccess=uno::Reference to (configmgr::RootAccess *) 0x619000028fb8, rNames=uno::Sequence of length 6 = {...}, bAllLocales=false) in core/unotools/source/config/configitem.cxx > #4 in utl::ConfigItem::GetProperties(this=0x61100000cad0, rNames=uno::Sequence of length 6 = {...}) in core/unotools/source/config/configitem.cxx > #5 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl(this=0x61100000cad0) in core/unotools/source/config/syslocaleoptions.cxx [...] Change-Id: I51127d82aea927dd9aaf374880c406dbafaddcde Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140658 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-09-27use more string_view in accessibility..configmgrNoel Grandin
Change-Id: Ie16d36faac7d06e275348ed68e6c6b2518534fd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140636 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-15Clean up color scheme migrationStephan Bergmann
...avoiding to have code in configmgr that knows about the details of the data stored in the configuration. (See the comments starting at <https://gerrit.libreoffice.org/c/core/+/139690/9#message-44703a2529c07bf1b0202ed3a232aa661784b159> "Migrating product name related color schemes between different versions" for details.) This reverts the dubious changes of 583ea856f2aa227bb04581c5bcdc3a402f5a184f "Migrating product name related color schemes between different versions" in configmgr and offapi. (Also, this moves the computation of sMigratedProductName in MigrationImpl::copyConfig, desktop/source/migration/migration.cxx, to a saner location than in the middle of the "check if the shared registrymodifications.xcu file exists" block where that 583ea856f2aa227bb04581c5bcdc3a402f5a184f had placed it.) Change-Id: I7ab3d57db19065c7c818e697300a2abd9e7f72bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139963 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-09-13Migrating product name related color schemes between different versionsBalazs Varga
Making work to migrate product name related color schemes with different kind of product names. For example from a product named by LibreOffice to a product named by LibreOfficeDev. Change-Id: Iabef982216f126b781df122ed258816af2ae337c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139690 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-07-21elide some makeStringAndClear() callsNoel Grandin
Change-Id: Id81a0c0046d0d84e6c327eef4447b21fecae6ddc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137283 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-23clang-tidy modernize-pass-by-value in configmgrNoel Grandin
Change-Id: If2e69c04e4d72ec6911fb435092275dbfffbf991 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134752 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-17Revert "use boost::flat_map in config_map"Tor Lillqvist
Fixes build breakage on macOS at least. Noel said it was OK to revert. This reverts commit cc4325f84a0ba35d8bbb564512bce0c6b8aab408. Change-Id: Ib78d29fc21d4d030b4032955b18271de1761f396 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134458 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-15use boost::flat_map in config_mapNoel Grandin
reduces time spent allocating Change-Id: Idd571db62d28be7e48672f76d741174a7ab40959 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134346 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-12elide temporary std::vector in Access::getElementNamesNoel Grandin
Change-Id: I9a875d5615930700e20f67c40b4b7a24458fd447 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134198 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-11avoid some ref-counting traffic in configmgr::Access:getNameInternalNoel Grandin
Change-Id: I3062855ab8f9ec9f1e7cdffe163f1c78865d5b9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-26Adapt function's interface to change from OUString to std::u16string_viewStephan Bergmann
...in 6fc3dfd3f1b5cb13101299df42444f2ff0493846 "use more string_view" Change-Id: Ibd1b8748e7a261cdb457a14ba87b1ec68d2a83de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133438 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-13use more string_view in configmgrNoel Grandin
Change-Id: Ia8aab5ea1a03d1512a1da806d505ce06f6977828 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132971 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-13loplugin:stringviewparam whitelist some more functionsNoel Grandin
for which we have o3tl:: equivalents Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-11use more string_viewNoel Grandin
found by tweaking the loplugin:stringview and making it whitelist getLength Change-Id: Ic41cd4e3026d93b70a76fe1279c6de3abbe6b4a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132820 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-02loplugin:stringviewparam convert methods using indexOfNoel Grandin
.. and lastIndexOf, which convert to find and rfind Change-Id: I6c4156cf904774c0d867f85a4c2785dba7593f62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132445 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-08Extend loplugin:stringview to O[U]StringBuffer::toStringStephan Bergmann
Change-Id: I7ad212dfff8b34d05e3b45107a1ef033a4efc454 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129651 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-13Recheck modules [a-c]* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I74a3c3a67c3639376e2251c3eb917fa4139dfbd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127808 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-12-21loplugin:flatten in canvas..cuiNoel Grandin
Change-Id: I208767eaa60d913fe2882403f1f9351eb08256f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127224 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-14tdf#81146: try to make saving registrymodifications.xcu more robustMike Kaganski
... by use of osl::File::replace, which is "atomic" on Windows, instead of osl::File::move. Change-Id: Ia49212f0d1cc75292f72ce219aee513e2d250ec4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126801 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-12-10Generally determine Rdb content from gb_*_set_componentfile callsStephan Bergmann
...instead of by listing the content somewhat redundantly in the Rdb_*.mk files, to avoid duplication of logic for components that are only built conditionally (and thus should only be included conditionally in the corresponding Rdb). To achieve that, add an "rdb" parameter to gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros that internally call gb_ComponentTarget_ComponentTarget), which is used to make the appropriate gb_Rdb_add_component call internally from within gb_ComponentTarget_ComponentTarget. (As a special case, gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that has already been done by the corresponding gb_Library_set_componentfile call, so allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to support that special case.) Most Rdb_*.mk files are thus mostly empty now. One exception is i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as needed during the build in CustomTarget_i18npool/localedata. 1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built components" had already tried to do something similar (in addition to other things) under a new --enable-services-rdb-from-build option. However, that approach had four drawbacks that this approach here addresses (and which thus partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b): 1 Rdb_services shall not contain the component files of all libraries that are built. While that commit filtered out the component files that go into Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files that go into others like Rdb_postgresql-sdbc (connectivity/Rdb_postgresql-sdbc.mk). 2 The code added by that commit to Makefile.gbuild codified the knowledge that there is an Rdb_services, which is brittle. 3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge (for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle. 4 Introducing an --enable-services-rdb-from-build option needlessly provided two different ways how the content of Rdb_services is assembled. The changes done here would leave --enable-services-rdb-from-build as a misnomer, as it no longer controls how Rdb_services is assembled. I thus renamed it to --enable-customtarget-components, as that is apparently what it still does now. Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-23fix configmgr --enable-dconf buildCaolán McNamara
error: no viable conversion from 'const char [1]' to 'std::u16string_view' (aka 'basic_string_view<char16_t>') and warning: instead of an 'rtl::OUString' constructed from a 'char16_t', pass a 'std::u16string_view' (or an 'rtl::OUStringChar') [loplugin:stringview] Change-Id: I0e611606190f063227c5467dc5a082277cebaaa0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125706 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-21osl::Mutex->std::mutex in configuration_registryNoel Grandin
Change-Id: If5561d6532716bfe3151f555a691aa5188264a1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125603 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-29Prepare for removal of non-const operator[] from Sequence in configmgrMike Kaganski
Change-Id: Ia349292783b81f0b4eebe64ae672ea5cb6d6cd59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124352 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-15loplugin:stringview (clang-cl)Stephan Bergmann
Change-Id: I367bc431bfd12041b2ccb6145c11f80b545aae19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123647 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-04 12:00:41 +0000