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: I20b38196ee1b6a34384dc46d9de1b6e1b44947ae
Due to the locale dependent date format used here in strings that
neither matches en-US nor en-GB (in which the tests seem to be
executed) all tests failed, and then with passCount==0 the check
was
If failCount <> 0 And passCount > 0 Then
instead of
If failCount <> 0 Or passCount = 0 Then
so the end result was OK.
Also fixed the one case that was commented with
Rem why this fails in excel?
It actually also failed for us, just that because all tests failed
(see above) it never seemed to fail..
Problem seems to be the accuracy of the underlying date+time
double for this specific calculation. Good to know it happens in
Excel as well ;-)
As a workaround, conversion to string does the necessary rounding
internally.
Change-Id: If0302b2feab9e1233d66da4eccff732f61542a69
Reviewed-on: https://gerrit.libreoffice.org/45196
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.
Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is type-safe, and allows to catch cases where a source type
is changed for some reason, but reinterpret_cast masks that
Change-Id: Ib64b6fa2e22d94a6bba890f0ccc3e20325c6f0a1
Reviewed-on: https://gerrit.libreoffice.org/42961
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* 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
rtl_[u]String_newConcat now checks allocation result to return
early and avoid SIGSEGV. Other functions are not modified, to
keep old behavior relying on allocation success and crashing
early on OOM to avoid added overhead in performance-critical
places.
OUString operator+= now checks rtl_uString_newConcat result and
throws std::bad_alloc on failure, to specifically address BASIC
problem. It keeps strong exception guarantee of leaving this'
state unaltered.
Concatenation in BASIC now checks for bad string allocation
(previously SIGSEGV was generated).
Unit test included.
Change-Id: I1513311d3d58eac43b2d2ec9a230e22dff0b4245
Reviewed-on: https://gerrit.libreoffice.org/37965
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
... making its value CRLF on Windows and LF on others.
A winding road of regressions passed through it;
first b680e352546dc614f3b30bbe212e6b415a6a6bf4,
then 7beeced463648fc67defea2ad48d58dd42f0ca1e.
Change-Id: I9e4da4a17436949b4fea35481b8355b4321cb268
Reviewed-on: https://gerrit.libreoffice.org/37500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
* Input of two-digit years only possible through CDateFromIso() though to
maintain compatibility with previous behavior and also VBA mode.
* VBA mode restricted to years 1..9999
Change-Id: Ia9574c3bf136619b4831b349d263c96b162d1ed4
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
