summaryrefslogtreecommitdiff
path: root/o3tl
AgeCommit message (Collapse)Author
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-09-24Drop some newly obsolete __GNUC__ version checksStephan Bergmann
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum version checks" Change-Id: I5f3bcda2ce8e0e093af3bdd9d2cca741a5b95306 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157202 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-06update loplugin:stringview* for o3tl::iterateCodePointsNoel Grandin
And change o3tl::iterateCodePoints to use sal_Int32 for its second param, to integrate better with places where the parameter comes from an UNO API, which cannot use std::size_t Change-Id: I7b9dd2c9bc7f48e6c4a912f039f1b5dae7beae69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151421 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-05Break comphelper::adjustIndexToStartOfSurrogate out of o3tl::iterateCodePointsStephan Bergmann
...as what they do is orthogonal (and it turned out that the use case that motivated the addition of o3tl::iterateCodePoints in the first place needs them independently, anyway) Change-Id: Id33901a2f7ac627253654ee6d883305dcf5a456f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151415 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-05Add some o3tl::iterateCodePoints testsStephan Bergmann
Change-Id: I00f7d8bbcf7588bb2d5df1bc6f68e2d5d224bd3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151414 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-24loplugin:unnecessarygetstr extend to more std::string checkingNoel Grandin
suggested by mike kaganski Change-Id: I5f5f254142767aca45a6101abdd84a0163ca6a34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150936 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-14loplugin:stringviewparam improvementsNoel Grandin
improve the check by checking for methods that exclude using string_view, rather than checking for methods that __can__ use string_view, which leads to exposing some holes in our o3tl/string_view.hxx coverage. Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-16Only specialize CppUnit::assetion_traits<T>::toString member functionsStephan Bergmann
...not the whole CppUnit::assetion_traits<T> classes (where applicable). That avoids spelling out the (identical) equals member functions, and also leaves around the less and lessEqual member functions, in case they want to be used after all. Change-Id: I18f8d6cff0353921ced4952b33a0c85ff8292923 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-24Fix MulDivSaturate to avoid overflowMike Kaganski
Thanks to Caolan https://gerrit.libreoffice.org/c/core/+/110839/comments/5c47cab2_b0523546 > oss-fuzz has come up with a case of n 9223372036854775807 m 72 d 127 > > include/o3tl/unit_conversion.hxx:105:28: runtime error: signed integer > overflow: 9223372036854775807 + 63 cannot be represented in type 'long' Change-Id: I0fe26f6c854a90cf577a60528d15f3da5471b914 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141711 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
generated by cgit (git 2.34.1) at 2024-04-28 11:06:27 +0000