based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
/** If a value is a valid argument for sin(), cos(), tan().
IEEE 754 specifies that absolute values up to 2^64 (=1.844e19) for the
radian must be supported by trigonometric functions. Unfortunately, at
least on x86 architectures, the FPU doesn't generate an error pattern for
values >2^64 but produces erroneous results instead and sets only the
"invalid operation" (IM) flag in the status word :-( Thus the application
has to handle it itself.
*/
chart2/source/tools/RelativePositionHelper.cxx
Function name: RelativePositionHelper::getCenterOfAnchoredObject
From here: suppose it's related to the orientation of the chart << 2^64
chart2/source/view/main/LabelPositionHelper.cxx
LabelPositionHelper::LabelPositionHelper
Suppose: setup label position.
There won't be angles grater than 360º.
chart2/source/view/main/PlottingPositionHelper.cxx
PolarPlottingPositionHelper::transformUnitCircleToScene
Suppose: maybe disc chart orientation?
Internal angle should be safe.
chart2/source/view/main/ShapeFactory.cxx
ShapeFactory::getSizeAfterRotation
Suppose: rotate shape
Internal angle should be safe.
drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx
Constant 100% safe
sc/source/core/data/documen4.cxx
bool ScDocument::Solver
Suppose: the tangent is being used as numerical derivative (Regula falsi algorithm)
So no impossible angles
scaddins/source/analysis/bessel.cxx
Filtered it out as bad imput
Change-Id: Ib348cca6ce13263d087b6731f93f58d8a15cc725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118193
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
can be a little expensive sometimes, since it loads a bunch of other
stuff at the same time.
So create a custom method that just loads the version
Change-Id: Ic480d95c4d64c68e57faf1b52f1d102141b7e246
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118047
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
During the import of the internal data table, incomplete
parsing of category labels with escaped quotation marks
resulted broken category labels and charts.
Change-Id: If5af3d527b80d1e055562f589bdaf17096ad49f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116714
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
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>
Currently, the dump() function used to debug charts only displays the
first line of headers, but actually headers can span several lines, so
some data is hidden.
Change-Id: Icbffa1d4dbaf8bb393504d2497f605a4e8f6b51d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110190
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
In practice, it works fine to look at all of them, regardless of actual argument
types.
Change-Id: Ifc49cbcd6003c8837c1b3f81d432c59fb0657bf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108366
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
Now Delete Data Labels and Insert Data Labels local
menu options remove custom label text instead of keeping it.
See with unit test document custom_data_label.xlsx of
commit bcda268cde
(tdf#134977 Chart OOXML: fix import of custom data label).
Change-Id: Ifc7afd0f2ece9da528e6206a6bd393b394b36f9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101929
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
because InternalDataProvider can not handle different category names
on the primary and secondary category axis.
Revert e0b0502516 commit, except
the relevant unit test.
Regression from commit: e0b0502516
(tdf#128016 Chart OOXML Import: fix duplicated category labels)
Also fix tdf#129994 (FILEOPEN - hang at import time), which is a
a regression from commit fa0a981af4
(tdf#114166 DOCX chart import: fix missing complex categories)
Change-Id: I5d049e760eb1a647ea774be264349a2f16f15f5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102463
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which disappeared, apparently by accident with...
commit 56e1133f72
Date: Sun Dec 8 19:33:42 2013 -0200
Convert chart 3D scene illumination to .ui
and then a bunch of cleanups removed the unused code
Change-Id: I53fe4f6878dda4f7b8d76a04213b5c6d1366a165
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101917
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Noel Grandin