summaryrefslogtreecommitdiff
path: root/winaccessibility/source
ModeNameSize
d---------UAccCOM1658logplain
d---------UAccCOMIDL263logplain
d---------service1166logplain
generated by cgit (git 2.34.1) at 2024-07-15 22:07:46 +0000
fb6c0b'>remove unused osl/mutex.hxx includesJochen Nitschke Change-Id: I3b50e45fdb99e9cd8bfda07356ee3ddb4dd0f8bb Reviewed-on: https://gerrit.libreoffice.org/38905 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de> 2017-06-16Make SfxItemSet ranges correct by constructionStephan Bergmann This is a follow-up to 45a7f5b62d0b1b21763c1c94255ef2309ea4280b "Keep WID ranges sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT) that each individual range has an upper bound not smaller than its lower bound. Arguably, all SfxItemSet instances should fulfill the stronger guarantees required and checked by MergeRange. And in many cases the ranges are statically known, so that the checking can happen at compile time. Therefore, replace the two SfxItemSet ctors taking explicit ranges with two other ctors that actually do proper checking. The (templated) overload taking an svl::Items struct should be used in all cases where the range values are statically known at compile time, while the overload taking a std::initializer_list<Pair> is for the remaining cases (that can only do runtime checking via assert). Most of those latter cases are simple cases with a single range covering a single item, but a few are more complex. (At least some of the uses of the existing SfxItemSet overload taking a const sal_uInt16* pWhichPairTable can probably also be strengthened, but that is left for another day.) This commit is the first in a series of two. Apart from the manual changes to compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and svl/source/items/itemset.cxx, it only consists of automatic rewriting of the relevant SfxItemSet ctor calls (plus a few required manual fixes, see next). But it does not yet check that the individual ranges are properly sorted (see the TODO in svl::detail::validGap). That check will be enabled, and the ensuing manual fixes will be made in a follow-up commit, to reduce the likelyhood of accidents. There were three cases of necessary manual intervention: * sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in braced-init-list syntax now, so needs explicit narrowing conversion to sal_uInt16. * In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually. * In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx, sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx, sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx, some comments had to be put back (see "TODO: the replaced range can contain relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx). A few uses of the variadic form erroneously used nullptr instead of 0 for termination. But this should have been harmless even if promoted std::nullptr_t is larger than promoted sal_uInt16, assuming that the part of the nullptr value that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly, some uses made the harmless error of using 0L instead of 0. Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35 Reviewed-on: https://gerrit.libreoffice.org/38861 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com> 2017-06-13Use unique_ptr in ItemPoolVectorStephan Bergmann Change-Id: I0ca2209d2fcbd7a16b67eee546b3ccc5393f2d42 2017-01-26Remove dynamic exception specificationsStephan Bergmann ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2016-11-09make comphelper::containerToSequence a little smarterNoel Grandin So we don't have to specify the source and destination type as often. Change-Id: Id9e286417a1cb246d163cbc3c536b231a4a92624 Reviewed-on: https://gerrit.libreoffice.org/30700 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> 2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e