aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
0 files changed, 0 insertions, 0 deletions
tion value='feature/refactor-god-objects'>feature/refactor-god-objects LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/store
AgeCommit message (Collapse)Author
2022-01-15Let loplugin:nullptr look into template instantiationsStephan Bergmann
It missed some occurrences of 0 when only looking into uninstantiated template code, as Clang doesn't model them with an ImplicitCastExpr, even if the target is known to be a (dependent) pointer type. Looking into all template instantiations of course carries the risk that a given use of 0 is meant to be interpreted as a pointer in some and as an integer in other instantiations. But the only case where that happened in the current code base is RegistryValueList::getElement (include/registry/registry.hxx), where {} is arguably a better choice anyway. (And which would presumably also hold for any future such cases.) Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-02clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I39b9ac81d65f4a269293824642c1b2ec593c0584 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121490 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-10tdf#143148:Use pragma once in storeEmircan Agac
Change-Id: Ia12dd3d7b69a8fdfbdfa6503e1ce2ee46c9446d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120075 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
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>
2020-11-18Replace #if with if constexpr()Mike Kaganski
This allows to test the actual type, not something unrelated Change-Id: I82d0714f6355fc5ae7bd3205af3472a43f1f1051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105998 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-16tdf#123936 Formatting files in module store with clang-formatPhilipp Hofer
Change-Id: I3bf0ea654f046172cab2566f357bc9c3354b8e6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105713 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-10-04loplugin:reducevarscope in store..svtoolsNoel
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-06-04loplugin:simplifypointertobool improve (2)Noel Grandin
to look for the x.get() == null pattern, which can be simplified to !x Change-Id: I0eddf93257ab53ab31949961d7c33ac2dd7288ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95400 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-03loplugin:simplifypointertobool improveNoel Grandin
to look for the x.get() != null pattern, which can be simplified to x I'll do the x.get() == nullptr pattern in a separate patch, to reduce the chances of a mistake Change-Id: I45e0d178e75359857cdf50d712039cb526016555 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354 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-05-10new loplugin:simplifypointertoboolNoel Grandin
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-14Revert "loplugin:constfields in stoc..svgio"Noel Grandin
This reverts commit 0ddf3e0a628599d01356cb5262b93faca073ee9f. Change-Id: I3e476399a465950defc15ac4d6199a638c4a4baf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90452 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-26cppcheck: shadowFunction in store/storbaseJulien Nabet
Change-Id: I836a5476a139c8c863c2e7c33e57c31dc3f6ab78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87432 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-25Change some #define to constexprStephan Bergmann
...plus loplugin:unnecessaryparen fallout in sw/source/uibase/docvw/edtwin.cxx. Each of the files contained at least one #define that would have caused warnings with upcoming loplugin:unsignedcompare. For consistency, I changed all #defines in those files (using a variable of a specific type if the original #define used a cast to that type, otherwise using 'auto'). Change-Id: I66f71b2d83394c9dc6952ae19df774cdd4d0b76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-22sal_Char->char in sot..storeNoel Grandin
Change-Id: Ia133c1a7549d81f2e88e34ab7e6c9ea578c745ae Reviewed-on: https://gerrit.libreoffice.org/85702 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-06loplugin:nullptrStephan Bergmann
...in non-dependent templated code that Clang trunk now apparently processes more aggressively, presumably since <https://github.com/llvm/llvm-project/ commit/878a24ee244a24c39d1c57e9af2e88c621f7cce9> "Reapply 'Fix crash on switch conditions of non-integer types in templates'" Change-Id: Ia3e4bc6cfe7cea9f816e9282563a8b38e40f0cec Reviewed-on: https://gerrit.libreoffice.org/84649 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-23cppcheck: performing init in init list (sfx2/slideshow/stoc/store)Julien Nabet
Change-Id: Iddbd3256aabe9552472b55d3d9b88a3769698de9 Reviewed-on: https://gerrit.libreoffice.org/83576 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
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-10-17Remove some memset callsMike Kaganski
Replace them with default initialization or calloc Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1 Reviewed-on: https://gerrit.libreoffice.org/80805 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-14loplugin:sequentialassign in starmath..svlNoel Grandin
Change-Id: I95d7b67cd8b6b68c087ff96fdb6bb283ab8b49ec Reviewed-on: https://gerrit.libreoffice.org/70718 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-29loplugin:flatten in stoc..storeNoel Grandin
Change-Id: Ib8c86179a3d13852cbb02b389b6103aca5456dba Reviewed-on: https://gerrit.libreoffice.org/67013 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-24loplugin:constparams in sd..svtoolsNoel Grandin
Change-Id: I50b864ffc4ed13ba801af46815988bf568b83d2e Reviewed-on: https://gerrit.libreoffice.org/66832 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-08tdf#42949 Fix IWYU warnings in store/source/*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I99f1611f41378a0baa7688db5a5f78e0169f0d5b Reviewed-on: https://gerrit.libreoffice.org/65649 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>