[API CHANGE] Resolves: tdf#42518 new KParseTokens::GROUP_SEPARATOR_IN_NUMBER

Default unset bit now does not accept/skip group separators in
numbers.

See .idl description comment for why this is incompatible and how.

This actually uncovered a "bug" (or at least unexpected) in the
Math parser that parsed "0," as one entity instead of "0" followed
by ",". As obtaining the text form appends a blank after each
entity the sw/qa/extras/rtfexport/rtfexport.cxx testMathEqarray()
testcase had to be adapted.

Change-Id: I2b605742ab3d8a9bb81ad6880faf050535dc80fa
Reviewed-on: https://gerrit.libreoffice.org/64270
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>

i18npool/source/characterclassification/cclass_unicode_parser.cxx

@@ -441,8 +441,15 @@ void cclass_Unicode::initParserTable( const Locale& rLocale, sal_Int32 startChar
         cDecimalSepAlt = aItem.decimalSeparatorAlternative.toChar();
     }
 
-    if ( cGroupSep < nDefCnt )
-        pTable[cGroupSep] |= ParserFlags::VALUE;
+    if (nContTypes & KParseTokens::GROUP_SEPARATOR_IN_NUMBER)
+    {
+        if ( cGroupSep < nDefCnt )
+            pTable[cGroupSep] |= ParserFlags::VALUE;
+    }
+    else
+    {
+        cGroupSep = 0;
+    }
     if ( cDecimalSep < nDefCnt )
         pTable[cDecimalSep] |= ParserFlags::CHAR_VALUE | ParserFlags::VALUE;
     if ( cDecimalSepAlt && cDecimalSepAlt < nDefCnt )
@@ -814,6 +821,8 @@ void cclass_Unicode::parseText( ParseResult& r, const OUString& rText, sal_Int32
                 }
                 if ( nMask & ParserFlags::VALUE )
                 {
+                    if (current == cGroupSep)
+                        nParseTokensType |= KParseTokens::GROUP_SEPARATOR_IN_NUMBER;
                     if ((current == cDecimalSep || (bDecSepAltUsed = (cDecimalSepAlt && current == cDecimalSepAlt))) &&
                             ++nDecSeps > 1)
                     {

offapi/com/sun/star/i18n/KParseTokens.idl

@@ -95,6 +95,28 @@ published constants KParseTokens
     /// Unicode (above 127) other number
     const long UNI_OTHER_NUMBER     = 0x00080000;
 
+    /** If this bit is set in <em>nContCharFlags</em> parameters, the
+        locale's group separator characters in numbers are accepted and
+        ignored/skipped. Else a group separator in a number ends the
+        current token. A leading group separator is never accepted. If
+        an accepted group separator was encountered in a number
+        (ParseResult::TokenType is KParseType::ASC_NUMBER or
+        KParseType::UNI_NUMBER) this bit is also set in
+        ParseResult::ContFlags.
+
+        <p> <strong>NOTE:</strong> absence of this bit in
+        <em>nContCharFlags</em> changes the default behaviour that in
+        prior releases accepted numbers with group separators but lead
+        to unexpected results when parsing formula expressions where the
+        user entered a (wrong) separator that happened to be the group
+        separator instead of an intended decimal separator. Usually
+        inline numbers in a formula expression do not contain group
+        separators.
+
+        @since LibreOffice 6.2
+     */
+    const long GROUP_SEPARATOR_IN_NUMBER = 0x08000000;
+
     /** If this bit is set in <em>nContCharFlags</em> parameters and a
         string enclosed in double quotes is parsed and two consecutive
         double quotes are encountered, the string is ended. If this bit

sw/qa/extras/rtfexport/rtfexport.cxx

@@ -210,7 +210,7 @@ DECLARE_RTFEXPORT_TEST(testMathEqarray, "math-eqarray.rtf")
 {
     OUString aActual = getFormula(getRun(getParagraph(1), 1));
     OUString const aExpected(
-        "y = left lbrace stack { 0, x < 0 # 1, x = 0 # {x} ^ {2} , x > 0 } right none");
+        "y = left lbrace stack { 0 , x < 0 # 1 , x = 0 # {x} ^ {2} , x > 0 } right none");
     CPPUNIT_ASSERT_EQUAL(aExpected, aActual);
 }