It should not convert strings to uppercase each loop; it should use
OUStringBuffer to avoid extra allocations.
This reduces tick count for the code in the bug from ~6000 to ~30.
Change-Id: I89ea062fc6d012464bb461b6a8ef321f8cc62fe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92884
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If a particular parameter type is requested during the
construction of a parameter list, don't convert missing
parameters to avoid implicit casting to the specified
data type and value of the method.
Missing parameters are handled in StepEMPTY, where
additional information about missing parameters is added.
Change-Id: Ia413b2996d7d1feecedc1dfefaf6baf0fd9d917e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90215
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For hex/octal literals take into account trailing suffix types
from GetSuffixType in basic/source/comp/scanner.cxx.
The suffix type $ (String) is not allowed for numeric values
or hex/octal literals and leads to a syntax error
(ERRCODE_BASIC_SYNTAX) during compile time.
Change-Id: Id6c4bbf1296361879f7dec461a48bbdc5c683338
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In order to load numeric values, generate SbiOpcode::NUMBER_ opcodes
including the numeric value and its data type instead of SbiOpcode::CONST_.
The numeric value and its data type will be restored in
SbiRuntime::StepLOADNC. When the new compiled code is stored in documents,
e.g. password-protected libraries, leagcy LO versions will just read up to
non-numeric characters, thus correctly obtaining number value and ignoring
the type, so the change is backward-compatible.
To interpret legacy compiled code, old treatment of SbiRuntime::StepLOADI
is restored, reverting commit 0b4f8bf571.
This change reimplements the fix for tdf#129596.
Change-Id: I46ebfc77f9bea69479968950c0fb7264e4a7ab27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90858
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Initialize default values of optionals in function headers.
In LO Basic, optional parameters are allowed, but without
any default values. Missing parameters will not be initialized
to their respective default values of its datatype, either.
With option Compatible, optional parameters are allowed
with default values. Missing optional parameters that
don't have explicit default values will not be initialized
to their default values of its datatype.
With option VBASupport, optional parameters are allowed with
default values. Missing optional parameters that don't have
explicit default values will be initialized to their default
values of its datatype.
Change-Id: I57aabae5f70d1cf6c4e8feb95ce0db6af753383c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87550
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The original
$(if $(filter 140,$(VCVER)),legacy_stdio_definitions)
had been added with d2a44e6270 "tdf#99696 fix
build error for 64bit Windows in unit tests using ADODB" at a time when
configure.ac supported VCVER=120 (i.e., VS 2013) and VCVER=140 (i.e., VS 2015).
It was presumably meant to express the condition
$(VCVER) >= 140
which is always true by now (where our baseline is already at VCVER=150, i.e.,
VS 2017).
Change-Id: I1cd48604d102c32e1d829395b65a00539f318b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89686
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...now that macOS builds are guaranteed to have std::optional since
358146bbbd "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Files which could become clang-format conformant with
under 5-percent lines of change relative to the total
count of lines in the file are found by using bin/find-clang-format.py,
and fixed with /opt/lo/bin/clang-format -i <path-of-the-file>
There will be follow-up patches to fix all 'under-5-percent' files.
Change-Id: Idc890cac4bb6aed4e36c3556a2abc0744fd086df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88770
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
With --enable-pch=full there's not much difference between a "public"
header in <module>/inc and a private one in <module>/src/somewhere/inc .
And since the script searches recursively, this apparently helps to
find even more headers for lower pch levels.
Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
check indentation of braces in namespace decls,
and the comments that often appear with them.
This is my penance for messing up the indentation with
clang-tidy-modernize-namespaces.
As such I have limited it to new-style namespaces for now,
and the check is off by default.
Change-Id: I4db7f10a81c79bc0eece8f8e3ee564da8bc7f168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87723
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
found using 'git grep', I tried using clang-tidy, but it only
successfully found a tiny fraction of these
Change-Id: I61c7d85105ff7a911722750e759d6641d578da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
During the generation of CONST_ expressions, distinguish between
integer and long and load the correct value in the immediate load step.
Change-Id: Ib4eb65d7fae3163043899ad8234816b1ebd7316b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Error to convert a value to number is signalled to user normally as a
standard Basic error; it's nothing a developer should worry about.
Change-Id: Ia6ca316f374ffe392eb1a7b4ffac52fd53ba2fb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86210
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This allows to correctly store and read Unicode strings used in
password-protected libraries. The additional data stored after all
legacy data of the stringpool record (after a magic number to mark
its presence), and so is invisible for older versions of program:
this allows to keep the version of data and backward compatibility.
Of course, older versions will only see legacy data, with broken
Unicode strings; and password-protected libraries edited and saved
in older versions will not contain Unicode data.
read_uInt16s_ToOUString and write_uInt16s_FromOUString are used
for correct handling of UTF-16 strings on LE/BE systems.
Change-Id: I990bc27b5cc7d499e71c43d45b7f263af41911e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86065
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... as seen in https://ci.libreoffice.org/job/gerrit_linux_gcc_release/48425/console
The problem was that SbxErrObject::getErrObject created a static object
which called GetSbxData_Impl() in its destructor, which in turn accessed
BASIC_DLL, which was invalidated by deleting BasicDLL objects either in
SfxApplication::~SfxApplication or in MacroSnippet::~MacroSnippet, thus
already invalid when static was destroyed.
So fix this by creating the global error object in the SbxAppData, not
as function-local static, so that its lifetime is limited to the data.
The crash happened also on Windows, but was somehow masked (possibly by
custom error handler?), with this call stack:
sblo.dll!std::unique_ptr<SbxAppData,std::default_delete<SbxAppData>>::operator*() Line 1886
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\memory(1886)
sblo.dll!GetSbxData_Impl() Line 110
at C:\lo\src\core\basic\source\runtime\basrdll.cxx(110)
sblo.dll!SbxBase::GetError() Line 96
at C:\lo\src\core\basic\source\sbx\sbxbase.cxx(96)
sblo.dll!SbxValue::Put(const SbxValues & rVal) Line 414
at C:\lo\src\core\basic\source\sbx\sbxvalue.cxx(414)
sblo.dll!SbxValue::Clear() Line 179
at C:\lo\src\core\basic\source\sbx\sbxvalue.cxx(179)
sblo.dll!SbxValue::~SbxValue() Line 139
at C:\lo\src\core\basic\source\sbx\sbxvalue.cxx(139)
sblo.dll!SbxVariable::~SbxVariable() Line 125
at C:\lo\src\core\basic\source\sbx\sbxvar.cxx(125)
sblo.dll!SbxProperty::~SbxProperty() Line 861
at C:\lo\src\core\basic\source\sbx\sbxobj.cxx(861)
sblo.dll!SbUnoProperty::~SbUnoProperty() Line 2591
at C:\lo\src\core\basic\source\classes\sbunoobj.cxx(2591)
sblo.dll!SbUnoProperty::`vbase destructor'()
sblo.dll!SbUnoProperty::`scalar deleting destructor'(unsigned int)
tllo.dll!SvRefBase::ReleaseRef() Line 163
at C:\lo\src\core\include\tools\ref.hxx(163)
sblo.dll!tools::SvRef<SbxVariable>::~SvRef<SbxVariable>() Line 56
at C:\lo\src\core\include\tools\ref.hxx(56)
sblo.dll!SbxVarEntry::~SbxVarEntry()
sblo.dll!SbxVarEntry::`scalar deleting destructor'(unsigned int)
sblo.dll!std::_Default_allocator_traits<std::allocator<SbxVarEntry>>::destroy<SbxVarEntry>(std::allocator<SbxVarEntry> & __formal, SbxVarEntry * const _Ptr) Line 677
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory(677)
sblo.dll!std::_Destroy_range<std::allocator<SbxVarEntry>>(SbxVarEntry * _First, SbxVarEntry * const _Last, std::allocator<SbxVarEntry> & _Al) Line 951
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xmemory(951)
sblo.dll!std::vector<SbxVarEntry,std::allocator<SbxVarEntry>>::_Destroy(SbxVarEntry * _First, SbxVarEntry * _Last) Line 1616
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\vector(1616)
sblo.dll!std::vector<SbxVarEntry,std::allocator<SbxVarEntry>>::_Tidy() Line 1698
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\vector(1698)
sblo.dll!std::vector<SbxVarEntry,std::allocator<SbxVarEntry>>::~vector<SbxVarEntry,std::allocator<SbxVarEntry>>() Line 674
at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\vector(674)
sblo.dll!SbxArray::~SbxArray() Line 75
at C:\lo\src\core\basic\source\sbx\sbxarray.cxx(75)
sblo.dll!SbxArray::`vbase destructor'()
sblo.dll!SbxArray::`vector deleting destructor'(unsigned int)
tllo.dll!SvRefBase::ReleaseRef() Line 163
at C:\lo\src\core\include\tools\ref.hxx(163)
sblo.dll!tools::SvRef<SbxArray>::~SvRef<SbxArray>() Line 56
at C:\lo\src\core\include\tools\ref.hxx(56)
sblo.dll!SbxObject::~SbxObject() Line 111
at C:\lo\src\core\basic\source\sbx\sbxobj.cxx(111)
sblo.dll!SbUnoObject::~SbUnoObject() Line 2387
at C:\lo\src\core\basic\source\classes\sbunoobj.cxx(2387)
sblo.dll!SbxErrObject::~SbxErrObject() Line 183
at C:\lo\src\core\basic\source\classes\errobject.cxx(183)
sblo.dll!SbxErrObject::`vbase destructor'()
sblo.dll!SbxErrObject::`scalar deleting destructor'(unsigned int)
tllo.dll!SvRefBase::ReleaseRef() Line 163
at C:\lo\src\core\include\tools\ref.hxx(163)
sblo.dll!tools::SvRef<SbxVariable>::~SvRef<SbxVariable>() Line 56
at C:\lo\src\core\include\tools\ref.hxx(56)
sblo.dll!`SbxErrObject::getErrObject'::`2'::`dynamic atexit destructor for 'pGlobErr''()
ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206
at minkernel\crts\ucrt\src\appcrt\startup\onexit.cpp(206)
ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) &,void <lambda>(void)>(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _execute_onexit_table::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204
at vccrt\vcruntime\inc\internal_shared.h(204)
ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void)>(const __acrt_lock_id lock_id, _execute_onexit_table::__l2::int <lambda>(void) && action) Line 975
at minkernel\crts\ucrt\inc\corecrt_internal.h(975)
ucrtbased.dll!_execute_onexit_table(_onexit_table_t * table) Line 231
at minkernel\crts\ucrt\src\appcrt\startup\onexit.cpp(231)
sblo.dll!__scrt_dllmain_uninitialize_c() Line 399
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\utility\utility.cpp(399)
sblo.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(182)
sblo.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 220
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(220)
sblo.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(293)
sblo.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 335
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(335)
ntdll.dll!LdrpCallInitRoutine()
ntdll.dll!LdrpProcessDetachNode()
ntdll.dll!LdrpUnloadNode()
ntdll.dll!LdrpUnloadNode()
ntdll.dll!LdrpUnloadNode()
ntdll.dll!LdrpDecrementModuleLoadCountEx()
ntdll.dll!LdrUnloadDll()
KernelBase.dll!FreeLibrary()
cppunitd_dll.dll!CppUnit::DynamicLibraryManager::doReleaseLibrary() Line 30
at C:\lo\src\core\workdir\UnpackedTarball\cppunit\src\cppunit\Win32DynamicLibraryManager.cpp(30)
cppunitd_dll.dll!CppUnit::DynamicLibraryManager::releaseLibrary() Line 69
at C:\lo\src\core\workdir\UnpackedTarball\cppunit\src\cppunit\DynamicLibraryManager.cpp(69)
cppunitd_dll.dll!CppUnit::DynamicLibraryManager::~DynamicLibraryManager() Line 19
at C:\lo\src\core\workdir\UnpackedTarball\cppunit\src\cppunit\DynamicLibraryManager.cpp(19)
cppunitd_dll.dll!CppUnit::DynamicLibraryManager::`scalar deleting destructor'(unsigned int)
cppunitd_dll.dll!CppUnit::PlugInManager::unload(CppUnit::PlugInManager::PlugInInfo & plugIn) Line 83
at C:\lo\src\core\workdir\UnpackedTarball\cppunit\src\cppunit\PlugInManager.cpp(83)
cppunitd_dll.dll!CppUnit::PlugInManager::~PlugInManager() Line 24
at C:\lo\src\core\workdir\UnpackedTarball\cppunit\src\cppunit\PlugInManager.cpp(24)
cppunittester.exe!`anonymous namespace'::ProtectedFixtureFunctor::run() Line 327
at C:\lo\src\core\sal\cppunittester\cppunittester.cxx(327)
cppunittester.exe!sal_main() Line 466
at C:\lo\src\core\sal\cppunittester\cppunittester.cxx(466)
cppunittester.exe!main(int argc, char * * argv) Line 373
at C:\lo\src\core\sal\cppunittester\cppunittester.cxx(373)
cppunittester.exe!invoke_main() Line 79
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79)
cppunittester.exe!__scrt_common_main_seh() Line 288
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
cppunittester.exe!__scrt_common_main() Line 331
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331)
cppunittester.exe!mainCRTStartup() Line 17
at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
Change-Id: I597dc242f71d220bbb42aef2611e4fd7e20a7be6
Reviewed-on: https://gerrit.libreoffice.org/85586
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...redux, after 51e7a59097 "Elide use of
rtl_Instance (which is obsoleted by C++11 thread-safe statics)" had done the
same in parallel but forgot to remove some now-unnecessary parts
Change-Id: I6c9d80c28b673ffb178d4f3cbd097b7d90891344
Reviewed-on: https://gerrit.libreoffice.org/85356
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 919689ac87 "Remove unused preliminary
entries from ImplRepository::m_aStore again" makes sure ImplRepository::m_aStore
doesn't accumulate references to UNO objects, which would only have been
destroyed upon exit, at which point that would easily have caused various
issues.
Change-Id: I6338a1ff46d72c137d619eabd8facca794028324
Reviewed-on: https://gerrit.libreoffice.org/85296
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The comment added to ImplRepository::getDocumentBasicManager by
8e74a57b6c "mib19: #163556# preserve VBA
compatibility in ODF roundtrip" explains why these preliminary entries are
created, but apparently forgot to remove them again when
ImplRepository::impl_createManagerForModel doesn't fill them.
Change-Id: I49ac77a8ca408c0b17d7a7bf7e939a468882ca13
Reviewed-on: https://gerrit.libreoffice.org/85261
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Caolán McNamara