extracts code from the innermost part of fairly hot loops
And add a GetIndexFromData method to make the call sites a little easier
to read.
Change-Id: I4ce5c5a687ecdb6982562a0aafce8513d86f9107
Reviewed-on: https://gerrit.libreoffice.org/49337
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
If only an hour is given (so no date part), copy behavior for table and query
and put 30/12/99 by default
Change-Id: Ifb371758538d2d11bd02b101a347d34816b6fddf
Reviewed-on: https://gerrit.libreoffice.org/48665
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins <ci@libreoffice.org>
The code used the odd combination of checking signed nFieldLen for != 0 and
<= USHRT_MAX, and then converting to sal_Int16 (not sal_uInt16) ever since
bf4154eb5307ec8c35f000fd1df39ef3abb2eb6d "initial import". But there are indeed
various MaxTextLen properties in offapi of type short, not unsigned short, so
for one assume that checking for <= SAL_MAX_INT16 (not SAL_MAX_UINT16) was
actually intended. And, for another, also assume that checking nFieldLen for
> 0 instead of != 0 was intended.
Change-Id: I119ef3ce71ee397cb6cbca714bca154e29e6599d
Reviewed-on: https://gerrit.libreoffice.org/48348
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@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: I91065e9ff1c160e5becda1ffa033de7c1b48b7f3
(after a to-be-committed improved loplugin:cstylecast would have rewritten the
C-style casts into static_casts)
Change-Id: Ife5e10c33c8e6abefd303445b8820c0d6f2d3307
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, 3af500580b1c82eabd60335c9ebc458a3f68850c
"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>
...that are not composed of multiple tokens, like ("foo" "bar"). Also don't yet
warn about Boolean literals, which are sometimes wrapped in parentheses to
silence unreachable-code warnings.
To avoid multiple warnings about code like
f((0))
switch to generally using a set of ParenExpr to keep track of which occurrences
have already been handled.
Change-Id: I036a25a92836ec6ab6c56ea848f71bc6d63822bc
Reviewed-on: https://gerrit.libreoffice.org/45317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Several bugs (AFAIK not filed into tdf bugzilla) fixed.
Remaining problems:
When some filter clauses go into WHERE and others in HAVING,
they are always logically ANDed (it cannot be any other way),
but that is not communicated to the user in the UI.
Some things left undone:
* DatabaseDataProvider (and its users?) needs to be updated
to be HAVING-aware, too.
* Form-based filter (.uno:FormFilter) not HAVING-aware
it reads the current filter in function
svxform::FormController::setFilter
in
svx/source/form/formcontrollers.cxx
That's one place that needs to be updated.
The other place is the one that applies the filter.
Change-Id: I0e9d30a1927b6739a16ae7627e8d0dae8823b376
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:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
std::binary_function is deprecated since C++11 and removed in C++17
90% done with regexp magic.
removed obsolete <functional> includes.
The std::binary_function base class was used by deprecated
std::bind2nd, this was solved in individual commits.
The members first_argument_type and second_argument_type were used
in chart2/source/controller/dialogs/DataBrowserModel.cxx:
DataBrowserModel::implColumnLess and are inlined in this commit.
Change-Id: I60ded60a8d4afd59e15ac15a58e18d2498c9be5a
Reviewed-on: https://gerrit.libreoffice.org/39659
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
std::unary_function is deprecated since C++11 and removed in C++17
90% done with regexp magic.
removed obsolete <functional> includes.
The std::unary_function base class was used in 3 places:
* chart2/source/tools/DataSeriesHelper.cxx: lcl_MatchesRole
is used in a std::not1 function helper who uses the members
return_type and argument_type.
- replace deprecated std::not1 with a lambda
* chart2/source/tools/ModifyListenerHelper.cxx:
lcl_weakReferenceToSame used the argument_type member in the
operator() parameter.
- inline the parameter type.
* xmloff/source/chart/SchXMLExport.cxx: lcl_SequenceToMapElement
used result_type and argument_type in operator().
- inline the types
Also fix compile error with gcc about finding std::for_each.
Change-Id: I073673beb01410c3108e7d0346d9e7d6b9ad2e2f
Reviewed-on: https://gerrit.libreoffice.org/39358
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
