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>
nStringSize is the actual size of the string block, and is the correct
end position to use to calculate last string length. nStringOff is not
updated during load, so using it makes no sense here.
It was this way ever since 039dbbcb96.
Change-Id: I4fad1bdd6ed4af9dd7d29b5438ec23db0b815806
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120243
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
In order to support the correct data type of numeric constants,
booleans, and default values for strings, the strategy to transport the
data type character to the runtime has been changed.
The type character will be added after the literal and the string
termination symbol in order to keep compatibility. This allows to
retrieve the correct type in StepLOADNC and in StepPARAM.
Any legacy written images are still possible to process, since if there
is a suffix type character where the data type character was directly
written after the numeric constant, it will be processed in StepLOADNC.
Without this fix, an optional parameter of type Variant, would still
include the suffixe type character, and will not be converted to the
correct type in StepPARAM.
Change-Id: I86c8192c6dc28457053fa7b23a073420e45407b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119945
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
In addtion, fixed a crash if the start position is greater than the
length of the string being searched.
Change-Id: I9bcda1131324bdfac6957018e91b3a36dd2dc3d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118996
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
In the old algorithm, some special unicode characters lead to a
malfunction of basic's replace function. For instance, replacing a
German ß to uppercase in the insensitive case will lead to SS, breaking
the replace positions.
Change-Id: I4e6f6e5fba3d560b8cfd0786fa2439ed5174a928
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118760
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
The LibreOffice's Basic Round function does not return values
that are compatible with VBA's Round. This can be easily fixed
using rtl/round, which has a flag parameter called
rtl_math_RoundingMode_HalfEven which rounds real numbers
exactly in the expected way.
Change-Id: I2215f08427e5777fc2d35f054b635dfa6247af8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118444
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This also fix the problem of basic_coverage tests not showing
the results when they were failing, since doUnitTest
returned a Integer
Change-Id: I637cd4cfaa34047bc99bfe6e0930f2945f1a9315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118234
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This makes sure that results of comparison of literals have proper boolean type,
and that this type is properly stored to/read from the string pool.
This introduces a new non-standard "type" character used in the pool: 'b'. It is
not a proper type character used in Basic (unlike '%'/'&'/'!'/'@'), but we have
to use this trick locally, because we need to pass the type that has no own type
character.
The change should be backward-compatible: older versions reading the value should
just ignore the 'b', and read the value as double.
Change-Id: Ibd4a70b366331342346eb171c8ed3c7026279596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117655
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It seems that, for some reason, the comparison operators for
strings in basic were swapped in the code that evaluates
string comparisons at compile-time. This is what caused
bug #142180. This commit simply swaps the operators and
should fix the bug.
Change-Id: I14f90db8598f2f7f8b709e26902986e1f64af576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115983
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
Inherit day, month and era names from en_US but with proper
values. See https://lh.2xlibre.net/locale/en_GB/
- Week definition (week)
- First day of week (first_weekday)
or
% LC_TIME=en_US locale -k LC_TIME
week-ndays=7
week-1stday=19971130
week-1stweek=1
first_weekday=1
first_workday=2
% LC_TIME=en_GB locale -k LC_TIME
week-ndays=7
week-1stday=19971130
week-1stweek=4
first_weekday=2
first_workday=2
This makes it necessary to adapt basic/qa/vba_tests/weekdayname.vb
because basic/qa/cppunit/test_vba.cxx sets LANGUAGE_ENGLISH_UK
Change-Id: I752bf0e59396f0cbd601beb596c07e77e4e4cfaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115160
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
* vbUnicode/vbFromUnicode considers optional third LCID argument.
* LCID is also used for other conversions.
* The encoding is decided based on the language defined in LCID,
or on program locale when LCID is omitted, using MS default
ACP mapping for languages.
* Unit testis for vbWide / vbNarrow are changed and enabled.
* Unit tests for vbKatakana / vbHiragana are changed and enabled.
* Unit test for vbFromUnicode / vbUnicode is changed to rely on
en-US locale used in testing, and is enabled.
Change-Id: Iabd4153db311cd02c3f3e7247f9fc71ad9f5f682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112539
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
Stephan Bergmann