summaryrefslogtreecommitdiff
path: root/svl/Library_passwordcontainer.mk
diff options
context:
space:
mode:
Diffstat (limited to 'svl/Library_passwordcontainer.mk')
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-01-23 04:32:52 +0000
highlight'> Change-Id: I35b8db34e722e700df2771da99d76d42fe2cada6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172640 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins 2024-05-14loplugin:ostr in svlNoel Grandin Change-Id: Idae670a53d6d9aab0ec7132077f3e7b7f6fa5287 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167595 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2024-03-22Related: tdf#160056 refactor SvNumberFormatterCaolán McNamara to split it into two constituent parts SvNFFormatData which is the data store for number formats it generally operates on. SvNFLanguageData for data around the current language in use. and then a SvNFEngine which implements the interaction between those parts SvNFEngine has two policies, the typical RW mode and a new RO mode where the SvNFFormatData doesn't change, all formats needed in this mode must already exist. Change-Id: I56b070ccd2e556a0cb1fe609a2fae28e18277c8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165146 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> 2023-05-26tdf#150028 Treat decimal separator after [SS]Laurent Balland Only decimal separator after S or SS was treated This change adds [S] and [SS] to treat formats like [SS].00 Update: correct export to XML Add QA unit tests Change-Id: I97ce4084d3caab2fcd18f1c70cd4221596290563 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151823 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com> 2022-07-01ChangeNullDate: assert valid date after normalization if it wasn't beforeEike Rathke ... and abort if not. Also take over only valid values. This might pop up more crashtest import failures that would need fixes similar to commit 7ca3eca66888a1fa1b7bd59d79bb8f4c96bd7460. Change-Id: I217204378374a1a598b5a3ff3c9c6728f112af70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136688 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2021-09-21Add ISO 8601 date+time with milliseconds formatEike Rathke NF_DATETIME_ISO_YYYYMMDDTHHMMSS000 YYYY-MM-DD"T"HH:MM:SS,000 using either ',' or '.' separator, '.' if Time100SecSep is '.' ',' else A prerequisite for tdf#88359 to not lose data when importing such, especially without "Detect special numbers" on. Change-Id: I02ab682636e6ddbcc4537183a3625ea61662f016 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122400 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2021-07-08Resolves: tdf#122191 BOOLEAN is a keyword, treat it as suchEike Rathke ... to not end up with "BOOL"E"AN" instead, which is a date type with an era year and literal strings. This never worked but only was uncovered by commit ce4fc2fc08be8ea2773194e303ed42d2579e93a0 CommitDate: Fri Mar 2 20:27:45 2018 +0100 Resolves: tdf#115351 convert boolean equivalent format codes to proper Boolean if the format also had to be converted between locales. Also preserve boolean equivalent formats during Excel export and try hard to convert back as much as possible if a literal boolean string format is a Boolean equivalent of the target locale. Change-Id: I54f65c276cbf7bb99e960b6d7053c5fa95fbccb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118591 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 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> 2020-12-01tdf#42949 Fix new IWYU warnings in directories s*Gabor Kelemen Except recently checked sc, sd, svx, sw Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice1b86628e4f22a39f307b9c5fa567b6ab9d5acb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106917 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.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-03Make ImpSvNumberformatScan::GetColor constMike Kaganski Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins 2020-09-03Simplify standard color initializationMike Kaganski Change-Id: Ife1c8365298fec713713739073b91d601b459e6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101990 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-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-05-30loplugin:simplifybool extend to expression like !(a < b || c > d)Noel Grandin mostly to catch stuff from the flatten work, but I think this looks good in general Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-02-16tdf#129878: replace error string for number format errors in CalcMohamed Sameh Change-Id: I9a7c98b656c1f9270de5b13f7022d5930a665a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88760 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2020-01-29cid#1458019 silence Out-of-bounds writeCaolán McNamara and cid#1458017 silence Out-of-bounds write Change-Id: I5411322bca523e5dc55b8df2e7d9261981f504da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87703 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2020-01-28New loplugin:unsignedcompareStephan Bergmann "Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-10-17Rename OUStringLiteral1 to OUStringCharStephan Bergmann It started out as a wrapper around character literals, but has by now become a wrapper around arbitrary single characters. Besides updating the documentation, this change is a mechanical for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f Reviewed-on: https://gerrit.libreoffice.org/80892 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-09-01Fix '..'Andrea Gelmini To complete this: https://gerrit.libreoffice.org/#/c/78312/ This is a massive replace for lines ending with ".." instead of "..." It passed "make check" on Linux. Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe Reviewed-on: https://gerrit.libreoffice.org/78356 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins 2019-02-11tdf#120703 PVS: V560 A part of conditional expression is always true/falseMike Kaganski Change-Id: Ib9ad5b874a210ef3862c668158fcc5d18eeab363 Reviewed-on: https://gerrit.libreoffice.org/67579 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2018-12-08Remove obsolete SAL_FALLTHROUGH completelyStephan Bergmann ...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b "HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now" Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937 Reviewed-on: https://gerrit.libreoffice.org/64800 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-11-14tdf#42949 Fix IWYU warnings in include/svl/*Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ide75232858599c275e023c2300201090acd22307 Reviewed-on: https://gerrit.libreoffice.org/63237 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2018-09-19Bin more binfilter cruftEike Rathke As the requirement for persistent keyword index values is gone, let's rearrange the keywords to a more logical and also gapless order, which allows to get rid of the cumbersome multiple loops in ImpSvNumberformatScan::GetKeyWord(). Change-Id: Ic1a034acc5f42f593b147a1baf377f1600fac118 Reviewed-on: https://gerrit.libreoffice.org/60692 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> 2018-09-18Bin binfilter cruftEike Rathke The requirement for persistent keyword index values is gone since long. Remove the NF_KEY_UNUSEDn place holders. Change-Id: Idcc1b621d88884ebcefb3ba4e7865d4f2db4ce51 Reviewed-on: https://gerrit.libreoffice.org/60643 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2018-09-18Use !startsWith() instead of indexOf()!=0Eike Rathke Faster and even easier to read. Change-Id: I0146f70ea250e68887ac5d8dd5a10fe7e6a90eeb Reviewed-on: https://gerrit.libreoffice.org/60648 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2018-08-17Do not convert YMD date order to YDM and vice versa, tdf#107012 follow-upEike Rathke Change-Id: I6362caae4dd0764a5f99f1b0453c17ecde4b53f1 Reviewed-on: https://gerrit.libreoffice.org/59213 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2018-08-16Resolves: tdf#119013 do not over-aggressively reorder date particlesEike Rathke In particular not when reading documents as we don't know what the original (default/system) locale was when the date format was created and stored and whether the format's date order actually matched the locale's ordering. Regression from commit 51478cefaa4e265b42e3f67eda0a64767ff3efba CommitDate: Tue Apr 18 17:01:27 2017 +0200 Resolves: tdf#107012 follow date order of the target locale Change-Id: I9d3bdbd512d95ed81ff6459e368a2d7497ec8a2d Reviewed-on: https://gerrit.libreoffice.org/59182 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins 2018-07-27ofz#7960 tight OUString concat loop causes libfuzzer oomCaolán McNamara it doesn't get a chance to release memory and falls over with an oom. Or something like that anyway. Change-Id: Ic99c1d1074146e38dc4aa5f63219aea345b11b2f Reviewed-on: https://gerrit.libreoffice.org/58183 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2018-06-20tdf#117575 treat thousand sep with ? in integer partLaurent BP '?' was missing when treating thousand separator However, format with '?' in integer part are not saved in ODF. Change-Id: I1d684a31f800f10bf9a04babb0b9fec34e28e72a Reviewed-on: https://gerrit.libreoffice.org/55901 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com> 2018-06-04Handle English vs locale's General keyword, tdf#33689 follow-up, tdf#107867Eike Rathke Caller of ImpSvNumberformatScan::GetKeyWord() needs to know if English or locale's keyword was found and act on it. Pointed out by an assert when attempting to copy "STANDARD" length characters (8) from "General" (7), which doesn't harm because when not in debug it copied the terminating 0-character. However, the keyword name also needs to be replaced for the locale's resulting format code. Change-Id: Ia5211b307ea44c1ba9c2b86786368355c570d4a2 Reviewed-on: https://gerrit.libreoffice.org/55293 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>