summaryrefslogtreecommitdiff
path: root/helpcontent2
diff options
context:
space:
mode:
Diffstat (limited to 'helpcontent2')
m---------helpcontent20
1 files changed, 0 insertions, 0 deletions
diff --git a/helpcontent2 b/helpcontent2
-Subproject 75587424015061e8fece16802fd0ab8c8d1ceed
+Subproject ef56bcc5c829fbf280b09bcfc584a805c452669
> ...where a signed and an unsigned value are compared, and the signed value has just been proven to be non-negative here Change-Id: I9665e6c2c4c5557f2d4cf1bb646f9fffc7bd7d30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133442 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-03-28drop operator bool and operator! from Bitmap and BitmapExNoel IRC chat: <quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap has the same problem as Graphic and the reason why you dropped that commit 7334034ae93b49fc93b5859a3c047a319d138282 "drop Graphic::operator bool" <noelgrandin> quikee[m], hmmm, good point <noelgrandin> maybe I should just drop both operator bool and operator! in favor of IsEmpty <quikee[m]> noelgrandin: I don't remember what the problem is I just remembered we dropped it Graphic :) sure, dropping everything for IsEmpty is probably the best Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-02-22forward declare some things and avoid includesCaolán McNamara Change-Id: I8bf6e23904c932de646aa84fffab1b5549dbdf31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111349 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2021-01-16tdf#138829 don't grab focus to roadmap label when sync timer firesCaolán McNamara Change-Id: Icc8a03a2ce5d63f3a2c477671a9aa52aefd1df96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109385 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2020-10-19use tools::Long in vclNoel Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-06-20tdf#133859 Wizard service: disable 'Next' button if path has only base itemIlhan Yesil If the wizard dialog for extensions has only the base item in the first path, there is no need to proceed to the next page, as there is no one. This will be checked and if so, the 'Next' button disabled. In libreoffice versions before 6.4, an ORoadmap class was used in the wizard. There, if the ORoadmap data are reinitialized, the InCompleteHyperLabel object must be destroyed first, before it will be set to nullptr. Change-Id: I5b4b2e6b3666b58acccace385c622f0a065fc368 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95969 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 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-10replace define by constexpr in vcl/roadmapJulien Nabet + move LABELBASEMAPHEIGHT in vcl/source/control/roadmap.cxx (only file where it's used) Change-Id: I22498bc7f6fa3f09a86f15844836a0b9bb3d7eb2 Reviewed-on: https://gerrit.libreoffice.org/82389 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2019-11-06loplugin:indentation find broken if statementsNoel Grandin so I don't read the "then" block as being a sequential statements Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c Reviewed-on: https://gerrit.libreoffice.org/82069 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-08-31hyperlabel.hxx can be a private header nowCaolán McNamara Change-Id: I52d01723ad4c4ece59f859726145d75aaa29321e Reviewed-on: https://gerrit.libreoffice.org/78346 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2019-08-31no need to include hyperlabel.hxxCaolán McNamara Change-Id: Iafa7d391c5a1b383a82b900f80c9f78f666ce340 Reviewed-on: https://gerrit.libreoffice.org/78345 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2019-08-31roadmap.hxx only used by vcl and toolkit nowCaolán McNamara Change-Id: I2a00687fbc53b2b5f2b8ad94e4813e778eb15f21 Reviewed-on: https://gerrit.libreoffice.org/78323 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2019-08-22loplugin:constmethod in vclNoel Grandin Change-Id: I20545527b117c9562b91076b748fb3e2659d2497 Reviewed-on: https://gerrit.libreoffice.org/77944 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-08-12Fix typosAndrea Gelmini Change-Id: I38e23114a257d1baf2a9f36fd8ac0fcf8f3938b3 Reviewed-on: https://gerrit.libreoffice.org/77356 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins 2019-08-07move Roadmap to vclCaolán McNamara Change-Id: I3ddb2a4906351d4134c14a1e9af710c9e7aeb5c6 Reviewed-on: https://gerrit.libreoffice.org/76900 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>