[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>
(cherry picked from commit 776f7e7463de3e97f3056712ee567f49a314829d)
Reviewed-on: https://gerrit.libreoffice.org/64355

1 files changed, 22 insertions, 0 deletions

diff --git a/offapi/com/sun/star/i18n/KParseTokens.idl b/offapi/com/sun/star/i18n/KParseTokens.idl
index ce5d355f0430..bc0f92c42c83 100644
--- a/offapi/com/sun/star/i18n/KParseTokens.idl
+++ b/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