Age | Commit message (Collapse) | Author |
|
See tdf#42949 for motivation
Change-Id: I109fa07d52721fd10354de07a2ed995ffa2f27c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132369
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
This resulted in segfault instead of a useful test failure message.
Was this way ever since 548b360c0e4693aac0cbdd2fcc1aab433fc54010,
and before in 6e31cbb4eaea3c6600248ba59a22853acc1d6606 and
9791453283407a0a129a71767a290058ac759da2.
Change-Id: I498d1c84a4eaf3e8180dedd67d1176cf6f8c1a60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118916
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
in unit tests
Change-Id: Id16731bbbe2f1b0e3642722d77aba04fc98db4cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93508
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Previously, for an XML like this:
<sharedItems>
<d v="2017-07-10T09:11:02"/>
<d v="2017-07-10T09:11:03"/>
<m/>
</sharedItems>
the call like
int pos = getXPathPosition(pDoc, "/x:sharedItems", "absent");
gave 3. That could result in mistakes, when a test would assert
on position "3" for a child element which name is mistyped.
I made such a mistake when creating a unit test trying to assert on
a position of the last element, and writing its name as "x:m", like
in rXPath itself; the return was 3, and I initially wrongly assumed
that the return is 1-based (like in xpath bracketed expressions).
rChildName made const OString&, for consistency with rXPath, or with
rAttribute in getXPath: child name is just a part of a longer xpath.
Change-Id: I7ba9c4466c75b1b10fce1ccf26ef3b56b4e11e87
Reviewed-on: https://gerrit.libreoffice.org/71614
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... to guarantee that e.g. getXPath will always fail for non-empty
non-existing attribute
Change-Id: I22cf932eda020abf16608341fcd1769b35478883
Reviewed-on: https://gerrit.libreoffice.org/70891
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|