qa « pyuno - lo/core - LibreOffice 核心代码仓库

LibreOffice 核心代码仓库

文档基金会

Mode	Name	Size
d---------	pytests	1011	log plain

gned 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