aboutsummaryrefslogtreecommitdiff
path: root/source/mr/dictionaries/en.po
AgeCommit message (Expand)Author
generated by cgit (git 2.34.1) at 2025-01-22 23:52:06 +0000
LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svx/source/form/fmundo.cxx
AgeCommit message (Collapse)Author
2024-11-08no need to take a copy of the getProcessComponentContext return valueNoel Grandin
we can just take a "const &". (found by running clang-tidy with the performance-unnecessary-copy-initialization warning) Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-10-26cid#1555767 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1555770 COPY_INSTEAD_OF_MOVE cid#1555788 COPY_INSTEAD_OF_MOVE cid#1555789 COPY_INSTEAD_OF_MOVE cid#1555798 COPY_INSTEAD_OF_MOVE cid#1555816 COPY_INSTEAD_OF_MOVE cid#1555822 COPY_INSTEAD_OF_MOVE cid#1555835 COPY_INSTEAD_OF_MOVE cid#1555845 COPY_INSTEAD_OF_MOVE cid#1555859 COPY_INSTEAD_OF_MOVE cid#1555864 COPY_INSTEAD_OF_MOVE cid#1555868 COPY_INSTEAD_OF_MOVE cid#1555892 COPY_INSTEAD_OF_MOVE cid#1555896 COPY_INSTEAD_OF_MOVE cid#1555921 COPY_INSTEAD_OF_MOVE cid#1555932 COPY_INSTEAD_OF_MOVE cid#1555935 COPY_INSTEAD_OF_MOVE cid#1555944 COPY_INSTEAD_OF_MOVE cid#1555952 COPY_INSTEAD_OF_MOVE cid#1555985 COPY_INSTEAD_OF_MOVE cid#1556024 COPY_INSTEAD_OF_MOVE cid#1556038 COPY_INSTEAD_OF_MOVE cid#1556042 COPY_INSTEAD_OF_MOVE cid#1556044 COPY_INSTEAD_OF_MOVE cid#1556060 COPY_INSTEAD_OF_MOVE cid#1556083 COPY_INSTEAD_OF_MOVE cid#1556085 COPY_INSTEAD_OF_MOVE cid#1556090 COPY_INSTEAD_OF_MOVE cid#1556136 COPY_INSTEAD_OF_MOVE cid#1556157 COPY_INSTEAD_OF_MOVE cid#1556159 COPY_INSTEAD_OF_MOVE cid#1556172 COPY_INSTEAD_OF_MOVE cid#1556179 COPY_INSTEAD_OF_MOVE cid#1556187 COPY_INSTEAD_OF_MOVE cid#1556255 COPY_INSTEAD_OF_MOVE cid#1556256 COPY_INSTEAD_OF_MOVE cid#1556266 COPY_INSTEAD_OF_MOVE cid#1556275 COPY_INSTEAD_OF_MOVE cid#1556290 COPY_INSTEAD_OF_MOVE cid#1556294 COPY_INSTEAD_OF_MOVE cid#1556301 COPY_INSTEAD_OF_MOVE cid#1556311 COPY_INSTEAD_OF_MOVE cid#1556318 COPY_INSTEAD_OF_MOVE cid#1556326 COPY_INSTEAD_OF_MOVE cid#1556369 COPY_INSTEAD_OF_MOVE cid#1556374 COPY_INSTEAD_OF_MOVE cid#1556387 COPY_INSTEAD_OF_MOVE cid#1556388 COPY_INSTEAD_OF_MOVE cid#1556417 COPY_INSTEAD_OF_MOVE cid#1556425 COPY_INSTEAD_OF_MOVE cid#1556435 COPY_INSTEAD_OF_MOVE cid#1556495 COPY_INSTEAD_OF_MOVE cid#1556497 COPY_INSTEAD_OF_MOVE cid#1556501 COPY_INSTEAD_OF_MOVE cid#1556503 COPY_INSTEAD_OF_MOVE cid#1556520 COPY_INSTEAD_OF_MOVE cid#1556523 COPY_INSTEAD_OF_MOVE cid#1556562 COPY_INSTEAD_OF_MOVE cid#1556573 COPY_INSTEAD_OF_MOVE cid#1556576 COPY_INSTEAD_OF_MOVE cid#1556598 COPY_INSTEAD_OF_MOVE cid#1556615 COPY_INSTEAD_OF_MOVE cid#1556626 COPY_INSTEAD_OF_MOVE cid#1556671 COPY_INSTEAD_OF_MOVE cid#1556689 COPY_INSTEAD_OF_MOVE cid#1556701 COPY_INSTEAD_OF_MOVE cid#1556713 COPY_INSTEAD_OF_MOVE cid#1556758 COPY_INSTEAD_OF_MOVE cid#1556759 COPY_INSTEAD_OF_MOVE cid#1556788 COPY_INSTEAD_OF_MOVE cid#1556811 COPY_INSTEAD_OF_MOVE cid#1556821 COPY_INSTEAD_OF_MOVE cid#1556824 COPY_INSTEAD_OF_MOVE cid#1556825 COPY_INSTEAD_OF_MOVE cid#1556862 COPY_INSTEAD_OF_MOVE Change-Id: I4925a79688a983bb07252600430039ec0bcb75b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175678 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-09-14use more concrete UNO types in svxNoel Grandin
Change-Id: I55fd67a66067f0c4f43ef182101c8d72a22fe3f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173325 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-11loplugin:ostr in svxNoel Grandin
Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-06svx: prefix members of SdrUndoActionMiklos Vajna
See tdf#94879 for motivation. Change-Id: Ieca2f1d0a8b781a908e3b4bd7fd7698305248a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167181 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-09loplugin:fieldcast in FmXUndoEnvironmentNoel Grandin
which means we can also use unique_ptr to manage this field. Change-Id: Icf31fa718af455148601efafbcc69067c5c27a16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159172 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-10-23Extended loplugin:ostr: Rewrite some O[U]StringLiteral -> O[U]StringStephan Bergmann
...in include files. This is a mix of automatic rewriting in include files and manual fixups (mostly addressing loplugin:redundantfcast) in source files that include those. Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-20Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: svxStephan Bergmann
Change-Id: Ib5028b826a3f62303b9e0502af70ad62c578fbb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158240 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18Clean up the remaining uses of OUStringConstExpr, and drop itStephan Bergmann
Change-Id: I30b2ac77b58e2ae1d1e997a0c830c513542b973d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158101 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-08cid#1547086 Logically dead codeCaolán McNamara
since: commit 757a73379dba01fde853443a09583d862c404531 Date: Fri Oct 6 09:31:28 2023 +0100 Related: cool#7373 add an SfxHintId::ThisIsAnSfxEventHint luckily this is the only use of SfxHintId::NONE so easy to audit Change-Id: Id593eb3b2c2d26c9552aa7bf6033afd4f3112120 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157678 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-06Related: cool#7373 add an SfxHintId::ThisIsAnSfxEventHintCaolán McNamara
to avoid cost of dynamic_cast of SdrHint to SfxEventHint Change-Id: Ie0366b7d7ba828d8ffabeed4d65d7c7b275a3ed4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157633 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-09-10using decls should come after #includeNoel Grandin
Change-Id: I058551e87bca42adede860f6f299b0f7ae2af3b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156798 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-05-03Just use Any ctor instead of makeAny in svxStephan Bergmann
Change-Id: I59b1b3f817a9028f132456ea5094f38f88674d00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-03Recheck modules sv* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I25779cbfb1aa93c31d6e12ac95e136b3bdbbc058 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130403 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-11-26loplugin:stringliteraldefine in svxNoel Grandin
Change-Id: I2375ebfe9791c43063ffbc8ddbe1bd365499a576 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125868 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-15loplugin:referencecasting in svxNoel
Change-Id: I072ba9da976cefd61f4a916e70b0601439e8a123 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110818 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
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-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-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-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-06loplugin:flatten in svxNoel Grandin
Change-Id: I31f33a5f693d5fdb8282181c5bd7f31971efe784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100236 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>