In particular if in any ForceArray context use the matrix result
instead of the array of references list.
Change-Id: I72328a690760637f6d31fadba447641c64711a67
... instead of a low precedence unary operator with an odd
behaviour. This wasn't documented nor specified but maybe needed
for old(est) binary file format compatibility. Generate an error
for anything else than a context of a function with one argument.
There might be some corner cases of documents where some old usage
leads to error now, of which some may have worked by accident, but
some not as intended.
Related, the internal not exposed (but available) NEG was classified
similar as a unary operator but corectly handled as function at all
places. Classified as an ordinary 1-parameter function as well.
Change-Id: I3d84a6382243c8d64313e37346f81c857e71be95
Reviewed-on: https://gerrit.libreoffice.org/50055
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I924954aefd471386805082f11a2d33db2746c49a
This way, it is possible to have all the strings translated in dialogs even
when different users use different languages. [It was already possible
to have different languages previously, but not everything in the dialog has
switched - like the buttons at the bottom of the dialogs etc.]
Change-Id: I29a5ae6d31a370eec60397884200b684ec1bf5b9
Reviewed-on: https://gerrit.libreoffice.org/46417
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/46979
Tested-by: Jenkins <ci@libreoffice.org>
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The mnRequestedLength fields in formula/ were introduced in
commit 6ef6dd0122
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date: Wed Feb 26 14:32:57 2014 -0500
Store the length of originally requested array size prior to
trimming.
but then partially removed in
commit d7f1f91b19
Author: Noel Grandin <noel@peralex.com>
Date: Mon Mar 3 13:29:43 2014 +0200
remove unused code in formula/vectortoken
Change-Id: Ic56b6e42682131ee45df7838867145f980f3d601
Reviewed-on: https://gerrit.libreoffice.org/45571
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and the vast majority of translations is to the ui language so default
ctor with that arg
and now drop OModuleResourceClient
Change-Id: I3b85a560ffdfe5f019c2271ac56a5fe4a361522b
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
e.g. helpid[s].hrc -> helpids.h
and insert include guards where missing
move "ordinary" defines into .hxx files
remove .hrc entries that are used as arguments to dialog factory
when a dedicated method can be added instead
Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
This one has no extra functionality at all, and its only purpose is to
be used in range-based for loops. If there is a cleaner way to do
this, feel free. Not sure if this functionality could or should be
combined with either of the two existing iterator classes related to
FormulaTokenArray (FormulaTokenIterator and
FormulaTokenArrayPlainIterator). Probably not.
Change-Id: I32599b0800fd2585624d3742a46ad4896ce7e47a
Instead, use FormulaTokenArrrayPlainIterator everywhere, especially in
the FormulaCompiler.
This is the final step of a long chain of commits. (Split up into many
"uncontroversial" bits, and then this, to make potential bisecting
easier.)
Also added a logging operator<< for FormulaTokenArray, for SAL_DEBUG,
SAL_INFO etc goodness.
Change-Id: I02fe29f3f1e0dc33e5cba69e594223b4178a12bc
Reviewed-on: https://gerrit.libreoffice.org/38851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
The plan is to drop the iterator functionality from FormulaTokenArray
and instead use separate iterator objects. This will make
parallelising code that uses these data structures easier. I call the
new separate iterator class FormulaTokenArrayPlainIterator for now,
feel free to come up with a better name.
No change to what code actually gets run yet, so yeah, this adds
"unused" code.
Change-Id: Ie86f80529354174f0ce8bde1085a54bc6c5ac67b
Obviously after FormulaTokenArray::Assign() or the copy-ctor for that matter,
new tokens can not be added anymore to the shrunk code array. We don't do it,
but ensure that it isn't done in future..
Change-Id: Ibc0115f9f38e9745028a7459c61408c188783d03
Julien Nabet