summaryrefslogtreecommitdiff
path: root/o3tl
AgeCommit message (Collapse)Author
2022-05-03remove the o3tl::lru_map "unlimited" hackLuboš Luňák
It didn't quite make sense before that maxsize == 0 meant no cleanup, and now with items optionally being count as having size more than 1 it makes even less sense to limit the size to max_size() of the containers. This comes from 16a338e173083954a9932a3a4005f17230, so instead make that special caller pass a large size, which in practice is the same. Change-Id: Id875862126200ba889211f6e4079ae5921f27650 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133690 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-02support custom item size (cost) for o3tl::lru_mapLuboš Luňák
When used with items that may vary significantly in size (such as SalLayoutGlyphsCache storing glyphs for texts of different sizes) limiting lru_map to just the number of items performs poorly, since it may use only small amount of memory if items are small or it may spent a huge amount of memory if items are large. As extra optional template argument to o3tl::lru_map that is a functor that provides cost of item each, and the total size is based on this instead of each item having cost 1. Change-Id: I2b326754fe63eb4bd20010d4cea615187407e26c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133672 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-04-20Avoid unhelpful loplugin:stringviewvarStephan Bergmann
Regression during `make check` introduced with ab699bfdb3375f7142a50cc35322e2924c9e5945 "new loplugin:stringviewvar looks for OUString vars that can be". Change-Id: Ib6b9aabcfd380b43a77a97cf9d7e15c37aeb852c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133204 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-09add a more complete o3tl::getTokenNoel Grandin
so we avoid OUString copying (mostly when doing stuff like parsing numbers of out of strings) Change-Id: I4ef6ac23671c0b40807a22158e655e92dfad4af6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-01use OUStringBuffer for a string that's modified often (tdf#145862)Luboš Luňák
SvParser::aToken was OUString despite being a buffer where the parsed result is collected. Change-Id: Id24c842738ea0f6f1836f77d855069963ac5ae55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130763 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-01fix o3tl::equalsIgnoreAsciiCase()Luboš Luňák
As the OUString equivalent shows, it needs to check == 0. Commit 33ecd0d5c4fff9511a8436513936a3f7044a775a for some reason also dropped the cheap checks (even from OUString) that OString has, so add them. Change-Id: I88e68b5ae10fd76c3c08b9b36d5abed0fad17bbf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130753 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2022-01-30Recheck modules [o-r]* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I6b4b05a5e59b256653c4caf5297fffd601b45083 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128845 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-12-22-Werror,-Wundef (clang-cl)Stephan Bergmann
Change-Id: Ife97d1645c0ef4684a00f943c649b19623290d7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127299 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-01improve the script for reducing symbol exportsNoel Grandin
And apply some of the results Change-Id: If555476fdd951cbc1d01fb3ef3ab1cbca2b64960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124896 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-30disable test under gcc 11.2.0Noel Grandin
Change-Id: Ic0d19cf827bc04026b5adf88bd5eb0a84e9dc270 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126080 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-21Some more o3tl::starts/ends_with overloadsStephan Bergmann
...including ones with a rest out parameter, modeled after their O(U)String counterparts and not present in any C++ standard (so intended to stay in o3tl, even when the C++20 wrappers are eventually removed again). Plus test code. These additional overloads will be used in forthcoming commits changing more places to use std string_view. Change-Id: Ifd05e0fdcb93e8751da22b8e4a59796ad00fe581 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122407 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-11convert some LogicToLogic calls to use o3tl::convert insteadTomaž Vajngerl
If a LogicToLogic uses fixed units, we can use o3tl::convert instead. We can also do the same for all other cases where LogicToLogic is used, but that needs additional investigation to determine if it is safe to do so. Note: MapUnit::Pixel is converted to o3tl::Length::pt because it assumed 72 PPI for a logical pixel, which corresponds with the conversion rate of a point (72 PPI). Today, 96 PPI is standard, which is also used for o3tl::Length:px. Change-Id: I29126df38bfcfda74b5d83d4cb880a378aecd18b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120230 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-08-10sw: remove all uses of MM50 with (added) o3tl::toTwipTomaž Vajngerl
MM50 constant is the number of twips for 5mm. This is (ab)used as a "shortcut" to set or compare various variables through the code and also to set a multiplied value (like 1cm, 2cm, 4cm) or divided value (2.5mm, 1.25mm). The problem with this is that converting the 5mm to twip doesn't round up exactly and multiplied and divided values increase the error even more. Instead of basing it from MM50 constant, it is just better to use our o3tl::convert (or the added variant o3tl::toTwip), which can actually calculate the conversion at compile time, so there is no added complexity at runtime and we get a more readable code with more exact result. i.e. o3tl::toTwip(4, o3tl::Length::cm) instead of the more cryptic MM50 * 8 In addition also sanitize and comment the values of the constants in sw/inc/swtypes.hxx. Change-Id: I85c306c36207d47ac3dc207094b68d0fb1ca5b70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119397 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-06-09allow altering the max size of o3tl::lru_cacheLuboš Luňák
Change-Id: Id119b70275e1c88a8c57f89d915241427be9dbf5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116927 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-05-11add o3tl version of hash_combine to not depend on boost for thisTomaž Vajngerl
Change-Id: I081f8d116ef811baa8aa5de35a6cb51fa4de7d56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114983 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-04-19Updated README.md filesHossein
* Updated README.md contents to fix various issues * Fixed source links by using [git:], processed by mkdocs scripts * Added README.md for ios, setup_native, unotest * Fixed issues with "underline" and "less than" sign Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-02-14Fix copy-paste leftoverMike Kaganski
Change-Id: If00eb6272443e1b97b6990141d091daa1d36dc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110881 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-14Move unit conversion code to o3tl, and unify on that in more placesMike Kaganski
This also allows to easily add more units, both of length and for other unit categories. The conversion for "Line" unit (312 twip) is questionable. Corresponding entries in aImplFactor in vcl/source/control/field.cxx were inconsistent (45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in commit c85db626029fd8a5e0dfcb312937279df32339a0. I haven't found a spec of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific). I used the definition based on "by pt", "by mm/100", "by char" (they all were consistent); "by pc" seems inverted; "by twip" was half as much. This accepted conversion makes unit test for tdf#79236 pass. Change-Id: Iae5a21d915fa8e934a1f47f8ba9f6df03b79a9fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110839 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-13Verify o3tl::temporary of a copied lvalue works as expectedStephan Bergmann
Change-Id: I454dd9308e7da4c7be4751eb643395ac483d6c43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108939 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-23Rename sorted_vector::erase(size_t) to erase_atJan-Marek Glogowski
emscripten clang fails with: sc/source/core/data/attarray.cxx:378:44: \ error: call to member function 'erase' is ambiguous aNewCondFormatData.erase(nIndex); ~~~~~~~~~~~~~~~~~~~^~~~~ include/o3tl/sorted_vector.hxx:86:15: note: candidate function size_type erase( const Value& x ) ^ include/o3tl/sorted_vector.hxx:97:10: note: candidate function void erase( size_t index ) This looks like a compiler error, but if the vector contained size_t values, this would also be ambiguous to begin with. So this just renames erase(size_t) to erase_at. And instead of a 2nd find in the failing code, after copying the vector, it mow uses std::distance to remove the item. Change-Id: I7d03ff32352a1890cc01ca241452c0f00d6a9302 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108212 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-11-18tdf#123936 Formatting files in module o3tl with clang-formatPhilipp Hofer
Change-Id: Ieb1229869cae8c14480243af98b270b9053fbde1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105691 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-05-26Don't run CompilerTest_o3tl_* with COMPILER_PLUGIN_TOOL=...Stephan Bergmann
...similar to 2228203a8211dea1c8addb98298096a094ec788b "Don't run CompilerTest_compilerplugins_clang with COMPILER_PLUGIN_TOOL=...", as otherwise e.g., `make check COMPILER_PLUGIN_TOOL=fakebool` failed with > o3tl/qa/compile-temporary.cxx:22:8: error: call to deleted function 'temporary' > f(&o3tl::temporary(n)); // expected-error {{}} expected-note@o3tl/temporary.hxx:* 0+ {{}} > ^~~~~~~~~~~~~~~ > include/o3tl/temporary.hxx:22:36: note: candidate function [with T = int] has been explicitly deleted > template <typename T> constexpr T& temporary(T&) = delete; > ^ > include/o3tl/temporary.hxx:21:36: note: candidate function [with T = int &] > template <typename T> constexpr T& temporary(T&& x) { return x; } > ^ Change-Id: I4dfa433708c064413f365375c84b85ced63c8d4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94871 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-22Adapt o3tl::span to removal of std::span::cbegin et alStephan Bergmann
<https://cplusplus.github.io/LWG/issue3320> "span::cbegin/cend methods produce different results than std::[ranges::]cbegin/cend", as implemented now in <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit; h=247f410b83797a1840573840cc2a539ef9d7f96b> "libstdc++: Remove std::span::cbegin and std::span::cend (LWG 3320)". Turns out we only used the removed member functions in o3tl/qa/test-span.cxx. Change-Id: I6c73797594b4e0e753a88840033d54961e271df5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89261 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-07Adapt o3tl::span to P1872R0Stephan Bergmann
..."span should have size_type, not index_type" (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1872r0.pdf>), as implemented by libc++ since <https://github.com/llvm/llvm-project/commit/ 1466335cf4b2854a0be1defcf279fe50772bad6f> "[libc++][P1872] span should have size_type, not index_type." All uses of index_type had been added to mitigate the previous std::span change from signed (ptrdiff_t) to unsigned (size_t) index_type, see 6ef8420fdbf8dff16de13147c5ab833bc5e01121 "Adapt o3tl::span to updated C++2a std::span". There is no easy solution to transparently support all three std::span variants currently out there (signed index_type, unsigned index_type, unsigned size_type), without causing compilation failures due to CPPUNIT_ASSERT_EQUAL with arguments of different types, or compiler warnings about mixed signed/unsigned comparisons. So rule out the oldest std::span variant (signed index_type) in configure.ac (so that o3tl::span will use its own hand-rolled code in that case) and simplify the uses of index_type to std::size_t (as had already been mentioned in 6ef8420fdbf8dff16de13147c5ab833bc5e01121). Change-Id: I6ddf424ffb7941da3f69ad66fd29ecd35f09afae Reviewed-on: https://gerrit.libreoffice.org/84652 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 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-08Introduce o3tl::unsafe_downcast for known-good dynamic_cast downcastsStephan Bergmann
(This helps rewrite code that silences Coverity unchecked dynamic_cast warnings, like 57b89ea1c2ff07b53c3cc002e5ec9e52abd0c1bd "coverity#704563 Unchecked dynamic cast", in a way that is cleaner and potentially executes faster.) Change-Id: I3319c0eeec2aa822f686feacd499a76c8c9b9499 Reviewed-on: https://gerrit.libreoffice.org/80458 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-08-23Mark move ctors/assignments noexceptMike Kaganski
This should enable using move semantics where possible e.g. in standard containers. According to https://en.cppreference.com/w/cpp/language/move_constructor: To make strong exception guarantee possible, user-defined move constructors should not throw exceptions. For example, std::vector relies on std::move_if_noexcept to choose between move and copy when the elements need to be relocated. Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb Reviewed-on: https://gerrit.libreoffice.org/77957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-02-20o3tl::make_unique -> std::make_unique in include/ & o3tl/Gabor Kelemen
Also the last few remaining occurrences of the header Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: I18f435270057f2d09e21d6ea262532cbcc974598 Reviewed-on: https://gerrit.libreoffice.org/67843 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-13array_view was changed to span in upcoming C++20Stephan Bergmann
...see <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf> "span: bounds-safe views for sequences of objects". o3tl::span is still an incomplete approximation of std::span; removed those o3tl::array_view members that are not present in std::span (and were not used in the code). Relies on C++17 __has_include to use standard <span> where available (e.g., in LLVM 7 libc++). Change-Id: I82a7e246b61b2456fa6183025d25eec4121ad3c9 Reviewed-on: https://gerrit.libreoffice.org/66215 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-11Drop o3tl/string_view.hxxStephan Bergmann
...now that all of its uses have been replaced with C++17 <string_view>. The LO-specific o3tl::basic_string_view ctors with OString and OUString params have meanwhile been replaced with OString and OUString conversion functions (in dac7be50cff94e0c34cdca5ac7e35c19685c40c1 "o3tl::string_view -> std::string_view (in configmgr)"), the ctor with OUStringLiteral turned out to be no longer(?) needed anyway, and the LO-specific o3tl::toOUString has meanwhile been replaced with an OUString ctor with std::u16string_view param (in 6856da30665705be6380e84cf55de954c41f15d1 "o3tl::string_view -> std::string_view (in embedserv)"). Change-Id: Ie5215b07e2387560fb7e94de8b5a963241539c64 Reviewed-on: https://gerrit.libreoffice.org/66144 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-16Fix o3tl::string_view streaming operator <<Stephan Bergmann
(The unnecessary os.setstate(std::ios_base::failbit) was due to a misreading of C++17 [ostream.formatted.reqmts]/1.) Change-Id: I7d8285230cb316c7af45c76029e9629517d05d56 Reviewed-on: https://gerrit.libreoffice.org/65217 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-07-Werror=catch-value=Julien Nabet
Change-Id: I58563735e6cf5004b4ac5e846885414f0c603f4c Reviewed-on: https://gerrit.libreoffice.org/61491 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-10-06Convert ImplFontCache to use o3tl::lru_mapJan-Marek Glogowski
We still do our own cleanup of the LRU map, as we can't drop any fonts in use. Change-Id: I8ec5c6ce8f80893635621357e9085950e7010f5b Reviewed-on: https://gerrit.libreoffice.org/61455 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-10-06Add a glyph-bound-rect cache to the font cacheJan-Marek Glogowski
This way the font cache can correctly invalidate the cached glyph rects when a font is dropped from the cache. Change-Id: I050866099742334f01cac1b872228a017ddb5e9b Reviewed-on: https://gerrit.libreoffice.org/61371 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-09-19implement find(T*) for o3tl::sorted_vector when it contains unique_ptr<T>Noel Grandin
and add some unit tests Change-Id: I9a01c9fa2fbbf3a553663a980ee6e958f9819645 Reviewed-on: https://gerrit.libreoffice.org/60737 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-08clang-tidy bugprone-use-after-moveNoel Grandin
Change-Id: I93c33da06f638ec6c8432bd13f992c320cfde93e Reviewed-on: https://gerrit.libreoffice.org/60158 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-06-01loplugin: look for CPPUNIT_ASSERT_EQUALS with params swappedNoel Grandin
idea originally from either tml or moggi, can't remember which Change-Id: Id78d75035036d3aa1666e33469c6eeb38f9e624d Reviewed-on: https://gerrit.libreoffice.org/55126 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-05-17New o3tl::temporary to simplify calls of std::modfStephan Bergmann
...that ignore the out-parameter integral part Change-Id: I05f07c1a8909023232f8aecf75ea5541d4eb81ca Reviewed-on: https://gerrit.libreoffice.org/54474 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-14Fix typoAndrea Gelmini
Change-Id: I87fce20463564fe9b32912fcbaf691c1c2839e2b Reviewed-on: https://gerrit.libreoffice.org/54201 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins <ci@libreoffice.org>
2018-05-13o3tl: add some comments to sorted_vector testTomaž Vajngerl
Change-Id: Iebedbb5afb45a92e52a8a390b9b7f6daae2337eb Reviewed-on: https://gerrit.libreoffice.org/54192 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2017-10-26Add test for o3tl::saturating_addStephan Bergmann
Change-Id: I19bb1d566bd80f859810b4023d965c8fd80b98f2
2017-10-25improve o3tl::enumarray const-nessNoel Grandin
Change-Id: I7b0d10b024edf604a7dea0e3b1399073f4bcba92 Reviewed-on: https://gerrit.libreoffice.org/43773 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-23loplugin:includeform: o3tlStephan Bergmann
Change-Id: I3cf4cda744148c966d0686310fef5dab6d3a3b35
2017-09-06const correctness in o3tl::array_viewNoel Grandin
Change-Id: I44c1ace97ae44069c5a0c6a247aa8a0b49896ad3 Reviewed-on: https://gerrit.libreoffice.org/41985 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-31loplugin:oncevarNoel Grandin
extend oncevar to any POD type Change-Id: Ia98ee0a67f183e40fb0c38477760124b2c411dc0 Reviewed-on: https://gerrit.libreoffice.org/40564 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-17create o3tl::array_viewNoel Grandin
A very basic implementation of the proposed std::array_view, similar to clang's llvm::ArrayRef. Mostly cribbed from the string_view implementation :-) Use it for the SfxDispatcher::setSlotFilter function Change-Id: Ife7e4971741b41827e145787899872c9b2bea82b Reviewed-on: https://gerrit.libreoffice.org/38817 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>