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>
This avoids repeated std::vector::resize in SbxArray::GetRef32 called from
SbxArray::Put32 called in loops for each array element when max index is
known in advance.
Change-Id: Ib2d1fe27820b9ede1426e206794f8cc729998841
Reviewed-on: https://gerrit.libreoffice.org/84722
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Restructure the StepDCREATE_IMPL code to do the preservation step before
creating the objects for the rest of array.
Change-Id: I4e4ba718af2da035b08397522e726eb131f813a4
Reviewed-on: https://gerrit.libreoffice.org/84706
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Regression after 0761f97525
The change replaced
// From 1996-03-06: take the HandleLast-Flag into account
sal_uInt16 nPos = r.m_Factories.size(); // Insert position
if( !pFac->IsHandleLast() ) // Only if not self HandleLast
{
// Rank new factory in front of factories with HandleLast
while (nPos > 0 && r.m_Factories[ nPos-1 ]->IsHandleLast())
nPos--;
}
r.m_Factories.insert(r.m_Factories.begin() + nPos, std::unique_ptr<SbxFactory>(pFac));
with
r.m_Factories.insert(r.m_Factories.begin(), std::unique_ptr<SbxFactory>(pFac));
Before that commit condition in while was always false, so decrementing
nPos had never happened, and insertion to the end was always performed.
This change restores that.
Change-Id: I778d6fdc93e9078a541a9b98c9432b5cf88d9791
Reviewed-on: https://gerrit.libreoffice.org/84609
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
The documentation of _getdcwd/_wgetdcwd specifies: "If the specified drive
isn't available, or the kind of drive (for example, removable, fixed, CD-ROM,
RAM disk, or network drive) can't be determined, the invalid-parameter handler
is invoked." (<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/
getdcwd-wgetdcwd?view=vs-2017>) The default handler terminates the process, so
temporarily install a "harmless" one.
(e30f3bcd25 "Revert 'fdo#38913: Prevent invalid
parameter handler crashes'" had removed a global "harmless" handler installed
with _set_invalid_parameter_handler to handle JVM-related issues, but which was
then considered no longer necessary. I assume that for those JVM-related issues
there was no obvious place where to install a temporary
_set_thread_local_invalid_parameter_handler, and that that was the reason for
the global _set_invalid_parameter_handler in sal_detail_initialize. I cannot
find any information that _set_thread_local_invalid_parameter_handler would be
available in fewer versions of Windows than _set_invalid_parameter_handler, and
might even be missing on Windows versions that we target.)
(It appears that at least when building with MSVC 2019 and running on Windows 8,
with an --enable-dbgutil build (presumably due to MSVC_USE_DEBUG_RUNTIME) a
"Microsoft Visual C++ Runtime Library: Debug Assertion Failed!" error dialog
still pops up, which needs to be quit with "Ignore" before our
invalidParameterHandler is called.)
Change-Id: I983d622eb03549873a63305f51bf0869d7fea33a
Reviewed-on: https://gerrit.libreoffice.org/84597
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reverts part of "loplugin:useuniqueptr in SbModule"
This reverts commit 263d732569.
because SbClassModuleObject is playing silly buggers with
ownership by messing with fields in its SbModule superclass.
Change-Id: I725332d080663e94b57f4bd4e1fb05aeeddf9038
Reviewed-on: https://gerrit.libreoffice.org/84352
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3 "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This gets rid of the last 72 lost bytes I could identify in the
huge valgrind logs to look like its PDF generation related.
Change-Id: Idda3c2c5b7f5ce0211199b86503037b74438ccf2
Reviewed-on: https://gerrit.libreoffice.org/83302
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I325149be2ea7697b5b4a2ce4a662edd2f8be6e50
Reviewed-on: https://gerrit.libreoffice.org/82312
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This reinstates the fix by Pierre Lepage, which was reverted in
351dead74b, and makes sure it only
has effect when the compilation is started from IDE.
The idea is that the IDE is used primarily for development, and
that's a good opportunity to detect any error in the code. When
the code is compiled from outside of the IDE (like running an
extension), the error is tolerated to allow users run the legacy
code having this error. Hopefully this is enough for tdf#106529.
This re-uses comphelper's NoEnableJavaInteractionContext class,
which is converted into general-purpose SetFlagContext class to
avoid code duplication.
Change-Id: Ie290019cb190b8d1d590699ec13bd63eac478d09
Reviewed-on: https://gerrit.libreoffice.org/81616
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Luboš Luňák