And simplify the latter, to always use "CDATA" type (as the former did).
"CDATA" was used in all cases but one, where an empty string was used.
Change-Id: I1b3bfae40e29628e4094d9a6e58a69a66865874c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we don't have to pass in the size of the string literal.
This is mostly a preparatory change, to make an another
patch of mine less noisy.
Change-Id: Idafcd68586b8b465e63dc89e4a4180d2e70ac3a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125080
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Remove overloads taking const char* which were not needed, because
every their use eventually took a string literal convertible to
OUString directly.
Many other literals were converted to OUStringLiterals.
Change-Id: Ia1e742a8087776cd20bf5094dc415dafd9a8834a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123155
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
noting that XMLTokenEnum was already being treated as being limited to
32-bits, we bitmask it together with namespaces
Change-Id: Ic48f2a662452d1b8e022078d31a723d2ac65aef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121707
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
LO without commit 519d96fd8b makes a mess
when storing form documents it has loaded from ODF 1.3 documents: the
XML parts are stored as ODF 1.2, but the storage (and therefore manifest
entry) keeps version 1.3.
To avoid this, store form documents as ODF 1.2 extended by default.
Unfortunately a bunch of ODF export code accesses the global
SvtSaveOptions variable; with this version override, only
SvXMLExport::getSaneDefaultVersion() must be used.
Change-Id: I5fa8e286f5103c578ed0d93da07a8a6cbe2f0ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115357
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression due to a combination of
commit 3de38e9556
Date: Tue Nov 10 19:20:06 2020 +0200
use fastparser in forms
and
commit 3d00847709
Date: Fri Dec 4 16:14:16 2020 +0200
fastparser in a couple of random places
The first one introduced the bug, due to the fallback
paths from fast to slowparser, things kept working, until
the second one removed the fallback.
Change-Id: I1aaae902eda2aaf8f5151404ddb3577f4582757d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111101
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Create a brand new odt file, add an image with form Control then save
You'll notice this on console:
warn:legacy.osl:20299:20299:xmloff/source/forms/propertyexport.cxx:680: OPropertyExport::dbg_implCheckProperty: invalid property type!
it's wrong since most of the type the exported property should be a OUString (internal "string")
but it may also be a graphic::XGraphic and this case isn't dealt by DBG_CHECK_PROPERTY
since we only gave it "OUString()"
Change-Id: I268b8d5f79c84ea73acdac245ee1705ddd009ae9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107653
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Wrong from:
2012-05-17 5e0b52c189
- (0 == _rPropValue.Name.compareToAscii(PROPERTY_EFFECTIVE_VALUE))
- || (0 == _rPropValue.Name.compareToAscii(PROPERTY_EFFECTIVE_DEFAULT)),
+ (0 == _rPropValue.Name.equalsAsciiL(PROPERTY_EFFECTIVE_VALUE.ascii, PROPERTY_EFFECTIVE_VALUE.length))
+ || (0 == _rPropValue.Name.equalsAsciiL(PROPERTY_EFFECTIVE_DEFAULT.ascii, PROPERTY_EFFECTIVE_DEFAULT.length)),
since '"compareToAscii" returned 0 if both strings are equal'
whereas "equalsAsciiL" returned sal_Bool (so sal_True if both strings equal)
there have been different changes during some years.
But c2d808a5dd (2019-02-01) did also wrongly this:
- OSL_ENSURE(
- _rPropValue.Name != PROPERTY_EFFECTIVE_VALUE
- && _rPropValue.Name != PROPERTY_EFFECTIVE_DEFAULT,
- "OControlImport::implTranslateValueProperty: invalid property type/name combination!");
+ SAL_WARN_IF(
+ _rPropValue.Name == PROPERTY_EFFECTIVE_VALUE
+ || _rPropValue.Name == PROPERTY_EFFECTIVE_DEFAULT, "xmloff",
+ "OControlImport::implTranslateValueProperty: invalid property type/name combination, Any and " + _rPropValue.Name);
Indeed the comment (which has never changed since 2001) above indicates:
"we have exactly 2 properties where this type class is allowed"
In brief, we want to warn if "_rPropValue.Name" different from "PROPERTY_EFFECTIVE_VALUE" and "PROPERTY_EFFECTIVE_DEFAULT"
Change-Id: I576b2af2eaf96c53ae7950b352239ce1510ff03c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106080
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
When empty sequence, there's nothing to convert so no need to spend time here and
to indicate the following warning:
Avoid warn:legacy.osl:93722:93722:xmloff/source/forms/elementimport.cxx:364:
OElementImport::implApplyGenericProperties: conversion to sequences other than 'sequence< short >' not implemented, yet!
+ avoid these in the same time:
warn:xmloff.forms:88800:88800:xmloff/source/forms/elementimport.cxx:428: DBG_UNHANDLED_EXCEPTION in implApplyGenericProperties
exception: com.sun.star.lang.IllegalArgumentException message:
/home/julien/lo/libreoffice/include/cppuhelper/proptypehlp.hxx:35 ArgumentPosition: 0
In addition, convert 2 OSL_ENSURE of this block in SAL_WARN_IF
Change-Id: I047eb5afba6fd22249010791aa61ebd1f83f3c67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106082
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mike Kaganski