...with the aid of an extended compilerplugins/clang/store/sfxitemsetrewrite.cxx
(which in turn needed a small addition to compilerplugins/clang/check.hxx).
Enable svl::detail::validGap check for the static case, but keep it disabled for
now for the dynamic case.
Change-Id: I4846ba8e99aff94a86518e2cb5044e575093386e
This is a follow-up to 45a7f5b62d "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>
...from 9ca8a63fff "Use consistent integer types
in the SwRedlineTable interface". This all started as an attempt to reduce the
number of places a to-be-committed improved loplugin:loopvartoosmall complains
about. Lets see where it ends...
SwRedlineTable::size_type is now the size_type of the underlying std::vector, no
longer sal_uInt16 from ancient times. I tried hard to find all places that are
affected by this change, changing types of affected variables and non-static
data members as needed. Some notes:
* The original code used USHRT_MAX as a "not found" value. I replaced that with
a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for
now of value USHRT_MAX. This should eventually be changed to something more
sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is
best done after we have constexpr support in all toolchains, so that npos can
be constexpr). It is important that the value of npos is towards positive
infinity, as many places in the code use
for (i = f(); // may return npos
i < table.size(); ++i)
table[i] ...
* There are some borders where values of SwRedlineTable::size_type are converted
into different types, for various reasons. But all of those other types
should be large enough for practical purposes (at least 32 bits wide):
MakrEntry::m_nIdx: long int
SvxRedlinTable::InsertEntry: sal_uIntPtr nPos
SwRangeRedline: size_t
SwRedlineItr: sal_Int32
SwVbaRevision::GetPosition: sal_Int32
SwXRedlines: sal_Int32
* .uno:TrackedChangeIndex= transports textual representations of such values.
libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as
strings, while SwTiledRenderingTest converts them to int.
* TODO: The one place I'm unsure about is SfxUInt16Items with IDs
FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE
in sw/source/uibase/uiview/view2.cxx. For now, I kept those as
SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from
those items. But I have no idea where instances of those items would actually
be created, and what it would mean to change those items' types?
Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8
Reviewed-on: https://gerrit.libreoffice.org/34775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
including fixing a bug in SwXMLExport::exportDoc where it was ORing with
a constant from a different type: nsRedlineType_t::REDLINE_INSERT
Change-Id: I2bb154c9a35d106e64fd1a8b6e928d0384c9fafe
This patch was created using a script
Variable name textual alignment is preserved to the same level
Change-Id: I6b4858f8059b8cf71fc253e87d6df634362d62e9
Reviewed-on: https://gerrit.libreoffice.org/26306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replaces the defensive programming band-aid of
5c1a1d1c66 with a real fix.
The problem is that lcl_NonCopyCount() has some special case code
to ignore the first node in the target document, which erroneously is
executed for every bookmark, which results in the 2 bookmarks in the
bugdoc being created with nDelCount 1 and 2 so they land on the same
node, which is not allowed for cross-reference marks.
Extract the adjustment into a separate function that is called once.
(regression from 689962feae)
Change-Id: Ie14c650f7fdb259c13cb9048226da30971d2ab3c
SplitNode() inserts new node before the existing one, so pEndTextNd and
aRg.aEnd point one node too far.
Change-Id: I6cea44fafd9d2b47e77e76892a260c5a8c6849fc
In copy/paste ignore the page break attribute from the first paragraph
of the document (see also tdf#39400)
Change-Id: I838c21c14647d4692673bd30df320e6704de1455
Reviewed-on: https://gerrit.libreoffice.org/22270
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>
For SwDoc::AppendDoc we use the StartOfContent node as the
starting copy node to prevent merging of the first node in
CopyRange and to get a 2nd node needed for CopyRange in case
of single content node documents.
This correctly counts StartOfContent as a non-copy node when
adapting the bookmark ranges for copying.
Change-Id: Ia3ee0328a1be5548f8751aa2240812c4662fb73f
Reviewed-on: https://gerrit.libreoffice.org/20383
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
This commit renames the most annoying abbreviations in Writer (and
partially in the shared code too).
Change-Id: I77e5134f42f25e3786afa36b7a505c7e3237a9e8
If the copied range starts with a not fully selected paragraph, the
bookmarks that are copied will be created on the wrong paragraphs,
on the node after the correct one.
This also happens when hinding the redlines, and causes asserts from
attempting to create CrossRefBookmarks on table nodes on WW8 export of
fdo66302-1.odt and fdo66312-1.odt.
Change-Id: Id576be3e38a89527d967f02b39d9aabbf6368354
