Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:\libcmis\inc\libcmis/document.hxx(51): warning C4589: Constructor of abstract class 'libcmis::Document' ignores initializer for virtual base class 'libcmis::Object'
C:\libcmis\inc\libcmis/document.hxx(51): note: virtual base classes are only initialized by the most-derived type
C:\libcmis\inc\libcmis/folder.hxx(58): warning C4589: Constructor of abstract class 'libcmis::Folder' ignores initializer for virtual base class 'libcmis::Object'
C:\libcmis\inc\libcmis/folder.hxx(58): note: virtual base classes are only initialized by the most-derived type
Change-Id: Icc7f94cc02796a86b47b025df69ec3db971ad11e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163777
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The LibreOffice Basic specification says CurDir should accept one
argument and in the case of a non-Windows system, ignore that argument
and simply return the current directory. So check that SbRtl_CurDir
accepts a maximum of two arguments.
Change-Id: Ia60114fac31aa4261c8251e26ef172a0370e6abc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163150
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
1. If passed new source URL is expanded (i.e., trying to expand it in
SfxLibraryContainer::checkStorageURL didn't change it), previously
aUnexpandedStorageURL was unchanged. It should be cleared - then it
will be set automatically to the URL to lib info file.
2. Try to create the "variable" path (starting with "$(USER)/basic/")
because this avoids absolute paths to the libraries, which make it
harder to move the profile.
Change-Id: Ie83ea9a32cfddf37727d238547663aeb72487ee3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162777
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
since:
commit 9cc8457abc
Date: Fri Dec 15 23:09:19 2023 -0700
tdf#128122 Updated BASIC CCur to reuse SvNumberFormatter
LibreOfficeOssFuzz.conf has --enable-ld=gold and that will just
crash on an unresolved symbol without any explanation, but building
without will give something useful, e.g.
sbxcurr.cxx:(.text._Z14ImpGetCurrencyPK9SbxValues[_Z14ImpGetCurrencyPK9SbxValues]+0x89f): undefined reference to `SbiInstance::GetNumberFormatter()'
/usr/bin/ld: sbxcurr.cxx:(.text._Z14ImpGetCurrencyPK9SbxValues[_Z14ImpGetCurrencyPK9SbxValues]+0xbf7): undefined reference to `SbiInstance::PrepareNumberFormatter(unsigned int&, unsigned int&, unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag> const*, DateOrder const*)'
Change-Id: I4b555760a609ec04fd85f7ba9c198a3d2ac712c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161294
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Previously, BASIC CCur used a custom, single-purpose currency string
parser which did not properly accommodate the user's locale setting.
This change replaces the custom parser with SvNumberFormatter, which
does correctly respect system locale.
Change-Id: I179915eb080e876e5e550dd350fdb86d7fa2bf4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160848
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Exponent in scientific number may use '?' as blank like in format "0.00E+?0"
This change:
- adds interpreatation of '0' and '?' in exponent
- adds "blank-exponent-digits" attribute to scientific number for import
and export to ODF
- prevents using exponent with only '?'. There must be at least one '0'
in exponent
- adds QA test of such format and test import/export/import to ODF and OOXML
- corrects one basic test
Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which would not work, as calling constexpr SbxVariable::MakeHashCode on those
vars would no longer be constant expressions
Change-Id: Ib848a6405dc270a1a5b9a92084fa2d063ea37892
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158134
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr
paths into a new TranslateId::getId. And demonstrate constexpr'ability by
making the aCategories var in OApplicationIconControl::Fill
(dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more
such cases that could now be made constexpr.)
Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead of returning ErrCode class everywhere, return a new
class ErrrCodeMsg, which combines an ErrCode with the other
parameters that are used to control the error reporting.
I do not change everything that uses ErrCode here, I started
from SfxBaseController/SfxMedium and worked outwards.
This change serves two purposes
(1) Replace the extremely whacky ErrorInfo mechanism we were
using to smuggle information into the error handler reporting
mechanism with a very straightforward approach of just combining it
into the error class.
(2) Allow us to capture the source location that produced the error,
which makes debugging the source of a problem soooo much easier.
Change-Id: I978b8f00c9851b41a216c7ebdef2ef94251d5519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157440
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 7fc6063914.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Adjusted the error message about exceeding legacy module size and
removed the code for saving image version 11. Modules using image
version 11 still can be loaded. Saving modules always result in
an image version higher than image version 11 depending on the
size of the module.
In addition, some minor performance issues (construction of the error
message and the correct list of modules) were fixed.
Change-Id: I3bde9fcc1596b63446193c836fa7b5cb06eb7d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149687
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
so presumably we no longer need this suppression since:
commit d969715fa4
Date: Wed Jul 19 22:29:35 2023 +0200
Simplify a bit by removing a redundant condition
line 627 already contains: if( nMaxDigit > nDigitPos )
Change-Id: If6ff93f91f5bd20a9a03ed828d6f4e598ff4f3da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154804
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
improve the check by checking for methods that exclude
using string_view, rather than checking for methods that
__can__ use string_view, which leads to exposing
some holes in our o3tl/string_view.hxx coverage.
Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mike Kaganski