(see the commit message of 4280a32579
"-Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): tools" about the
recent need of some "clang-format off" in tools/source/misc/json_writer.cxx), in
case we would ever bump our clang-format version
Change-Id: I4ee9385f84db415903790332c81161c5dbc7614f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142350
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(The "clang-format off" in tools/source/misc/json_writer.cxx is necessary
because otherwise the code between the SAL_WNODEPRECATED_DECLARATIONS_PUSH/POP
macros would be ill-formatted in a way that would trigger loplugin:indentation.)
Change-Id: Ic96787865d4c96be07c41f4939893420dfa04046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142339
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so it's unclear why 2f5f45921b "support
O(U)String::number() for fast string concatenation" added that here.
On the contrary, variables of type OStringNumber can be useful replacements for
calls to std::sprintf (which started to emit deprecation warnings with
macOS 13 SDK now), so this is in preparation for follow-up commits that will
replace many uses of that across the code base with various alternatives.
Change-Id: I6f8508d49dc84773c50f4c33dba38fe08c4c8969
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142318
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in preparation for follow-up commits that will replace many uses of
std::sprintf (which started to emit deprecation warnings with macOS 13 SDK now)
across the code base with various alternatives
Change-Id: I9602f1cb0e28d1b70c2356edb52d78dd165f1118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...originally done with 1d7964c5ff "CWS-TOOLING:
integrate CWS unifypaper01" on 2009-06-12. However, the removed
lcl_GuessPaperSize then reappeared, apparently with the merge commit
4563270cfd "CWS-TOOLING: integrate CWS
printerpullpages" on 2010-01-15, presumably due to a mis-merge somewhere along
the way.
SmModel::getRenderer and SmModel::render are e.g. called when doing "Export as
PDF..." of a Math Formula, but it seems a bit hard to get into the "no real
printer" branches there that would actually have called lcl_GuessPaperSize. But
anyway, it looks reasonable to replace that function with the more elaborate
SvxPaperInfo::GetDefaultPaperSize.
(I stumbled over this when the code in lcl_GuessPaperSize caused a newly
introduced -Werror=dangling-reference with GCC 13 trunk, similar to
e0121b2478 "-Werror=dangling-reference". So I
figured I'd remove that code as apparently intended back in 2009 rather than try
to fix it now.)
Change-Id: Ia73d9ece8429bbeccd4f65a9efc156c0dee52c01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d2249cd9adf5ae638577139177a50f7e62d8abd9>
"c++: Implement -Wdangling-reference [PR106393]" grew a new warning, included in
-Wall, and based on some more-or-less shaky heuristics, that warns about
"possibly dangling reference to a temporary". It produces quite a number of
false positives, but for these uses of SfxItemSet::Get it does look plausible
that the returned item references could, at least in theory, point at data that
is destroyed along with the temporary SfxItemSet.
Change-Id: I11afc4512db488f73170c6cfa706e9e094209550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142217
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which started to hit me now either due to building against a recent Visual
Studio 2022 Preview 17.4 (which would presumably no longer define those macros
in some system headers, so that the #ifndef's started to kick in now), or due to
building against a more recent Windows SDK (see below), no idea which.
But just dropping the seemingly unused macro definitions from the various .cxx
caused builds against old Windows SDK versions like Jenkins
<https://ci.libreoffice.org/job/gerrit_windows/139228/> to fail like
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(479): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(480): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(481): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(482): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(503): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(504): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(505): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(506): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(667): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(668): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(669): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(670): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(691): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(692): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(693): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(694): error C3861: 'min': identifier not found
[...]
> make[1]: *** [C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/solenv/gbuild/LinkTarget.mk:334: C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/CxxObject/vcl/win/app/salinst.o] Error 2
so move those macro definitions to prewin.h (where they don't trigger clang-cl's
-Werror,-Wunused-macros from within an include file, even if they happen to be
unused in a translation unit). (For simplicity, see whether it works in
practice to drop those #ifndef wrappers. If they turn out to be relevant for
some build scenarios after all, they can be added back.)
Change-Id: I76d8794ae2de310bdca420e5488db2bc19de23ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142090
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> vcl/win/gdi/salbmp.cxx(179,9): error: member 'getSystemDependentData' found in multiple base classes of different types
> getSystemDependentData<SystemDependentData_GdiPlusBitmap>());
> ^
> vcl/inc\salbmp.hxx(138,24): note: member found by ambiguous name lookup
> std::shared_ptr<T> getSystemDependentData() const
> ^
> include\basegfx/utils/systemdependentdata.hxx(107,39): note: member found by ambiguous name lookup
> SystemDependentData_SharedPtr getSystemDependentData(size_t hash_code) const;
> ^
> vcl/win/gdi/salbmp.cxx(217,9): error: member 'addOrReplaceSystemDependentData' found in multiple base classes of different types
> addOrReplaceSystemDependentData<SystemDependentData_GdiPlusBitmap>(
> ^
> vcl/inc\salbmp.hxx(147,24): note: member found by ambiguous name lookup
> std::shared_ptr<T> addOrReplaceSystemDependentData(Args&&... args) const
> ^
> include\basegfx/utils/systemdependentdata.hxx(106,14): note: member found by ambiguous name lookup
> void addOrReplaceSystemDependentData(SystemDependentData_SharedPtr& rData);
> ^
Change-Id: I8b8d034e4e3a0bcd4462f3b28246b219632960ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142089
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that had been added in 48b1c8898d "clang-cl
loplugin: vcl", apparently to avoid redeclaration warnings for some extern "C"
function, and had been left behind when that function declaration was removed in
3c443852d2 "vcl: remove no longer needed
WIN_Rectangle()"
Change-Id: I2744122e8fefc56c75dbcb921e96b22025b6b766
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141909
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for recent Visual Studio 2022 Preview 17.4.0 (which can be installed
alongside a Visual Studio 2022 17.3.x release)
Change-Id: I104363ac0007a84617486dd798d6c4fb9c0a5ea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141855
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...at least when building with Visual Studio 2022 Preview 17.4.0,
> In file included from workdir/UnpackedTarball/skia/src/core/SkKeyHelpers.cpp:14:
> workdir/UnpackedTarball/skia\src/core/SkShaderCodeDictionary.h(45,43): error: no type named 'string' in namespace 'std'
> using GenerateGlueCodeForEntry = std::string (*)(const std::string& resultName,
> ~~~~~^
etc.
Change-Id: Idd8dafb4e57e04088ee60954ecfa601cc7588e55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141833
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from sfx2/source/dialog/templdlg.cxx:20:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'ToolbarDropTarget'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<ToolbarDropTarget>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<ToolbarDropTarget>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> sfx2/source/dialog/templdlg.cxx:665:25: note: in instantiation of member function 'std::unique_ptr<ToolbarDropTarget>::~unique_ptr' requested here
> SfxTemplateDialog_Impl::SfxTemplateDialog_Impl(SfxBindings* pB, SfxTemplatePanelControl* pDlgWindow)
> ^
> sfx2/source/inc/templdgi.hxx:198:7: note: forward declaration of 'ToolbarDropTarget'
> class ToolbarDropTarget;
> ^
Change-Id: I360f35e01e301bca6fa801a889b6d107f67faf15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141818
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from sw/source/core/access/acccell.cxx:20:
> In file included from include/sal/log.hxx:20:
> In file included from ~/llvm/inst/bin/../include/c++/v1/sstream:186:
> In file included from ~/llvm/inst/bin/../include/c++/v1/istream:165:
> In file included from ~/llvm/inst/bin/../include/c++/v1/ostream:168:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'FndLine_'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<FndLine_>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<FndLine_>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:64:13: note: in instantiation of member function 'std::unique_ptr<FndLine_>::~unique_ptr' requested here
> __loc->~_Tp();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:89:12: note: in instantiation of function template specialization 'std::__destroy_at<std::unique_ptr<FndLine_>, 0>' requested here
> _VSTD::__destroy_at(__loc);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/allocator_traits.h:317:16: note: in instantiation of function template specialization 'std::destroy_at<std::unique_ptr<FndLine_>, 0>' requested here
> _VSTD::destroy_at(__p);
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:834:25: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<std::unique_ptr<FndLine_>>>::destroy<std::unique_ptr<FndLine_>, void, void>' requested here
> __alloc_traits::destroy(__alloc(), std::__to_address(--__soon_to_be_end));
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:828:29: note: in instantiation of member function 'std::vector<std::unique_ptr<FndLine_>>::__base_destruct_at_end' requested here
> void __clear() _NOEXCEPT {__base_destruct_at_end(this->__begin_);}
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:433:9: note: in instantiation of member function 'std::vector<std::unique_ptr<FndLine_>>::__clear' requested here
> __clear();
> ^
> sw/inc/tblsel.hxx:170:5: note: in instantiation of member function 'std::vector<std::unique_ptr<FndLine_>>::~vector' requested here
> FndBox_( SwTableBox* pB, FndLine_* pFL ) :
> ^
> sw/inc/tblsel.hxx:152:7: note: forward declaration of 'FndLine_'
> class FndLine_;
> ^
Change-Id: Ia088547c6463a55f48bb4c4ca5107b3bf9472ff1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:43:
> In file included from vcl/inc/unx/gtk/gtkdata.hxx:34:
> In file included from vcl/inc/unx/gendata.hxx:15:
> In file included from vcl/inc/svdata.hxx:26:
> In file included from include/o3tl/hash_combine.hxx:13:
> In file included from ~/llvm/inst/bin/../include/c++/v1/functional:515:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__functional/boyer_moore_searcher.h:26:
> ~/llvm/inst/bin/../include/c++/v1/vector:538:52: error: arithmetic on a pointer to an incomplete type 'FilterEntry'
> {return static_cast<size_type>(__end_cap() - this->__begin_);}
> ~~~~~~~~~~~ ^
> ~/llvm/inst/bin/../include/c++/v1/vector:761:56: note: in instantiation of member function 'std::vector<FilterEntry>::capacity' requested here
> __annotate_contiguous_container(data(), data() + capacity(),
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:428:7: note: in instantiation of member function 'std::vector<FilterEntry>::__annotate_delete' requested here
> __annotate_delete();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:49:5: note: in instantiation of member function 'std::vector<FilterEntry>::~vector' requested here
> delete __ptr;
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<std::vector<FilterEntry>>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:86:19: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::~unique_ptr' requested here
> SalGtkFilePicker::SalGtkFilePicker( const uno::Reference< uno::XComponentContext >& xContext ) :
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.hxx:38:8: note: forward declaration of 'FilterEntry'
> struct FilterEntry;
> ^
> In file included from vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:43:
> In file included from vcl/inc/unx/gtk/gtkdata.hxx:34:
> In file included from vcl/inc/unx/gendata.hxx:15:
> In file included from vcl/inc/svdata.hxx:26:
> In file included from include/o3tl/hash_combine.hxx:13:
> In file included from ~/llvm/inst/bin/../include/c++/v1/functional:515:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__functional/boyer_moore_searcher.h:26:
> ~/llvm/inst/bin/../include/c++/v1/vector:761:54: error: arithmetic on a pointer to an incomplete type 'const value_type' (aka 'const FilterEntry')
> __annotate_contiguous_container(data(), data() + capacity(),
> ~~~~~~ ^
> ~/llvm/inst/bin/../include/c++/v1/vector:428:7: note: in instantiation of member function 'std::vector<FilterEntry>::__annotate_delete' requested here
> __annotate_delete();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:49:5: note: in instantiation of member function 'std::vector<FilterEntry>::~vector' requested here
> delete __ptr;
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<std::vector<FilterEntry>>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:86:19: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::~unique_ptr' requested here
> SalGtkFilePicker::SalGtkFilePicker( const uno::Reference< uno::XComponentContext >& xContext ) :
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.hxx:38:8: note: forward declaration of 'FilterEntry'
> struct FilterEntry;
> ^
> In file included from vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:43:
> In file included from vcl/inc/unx/gtk/gtkdata.hxx:34:
> In file included from vcl/inc/unx/gendata.hxx:15:
> In file included from vcl/inc/svdata.hxx:26:
> In file included from include/o3tl/hash_combine.hxx:13:
> In file included from ~/llvm/inst/bin/../include/c++/v1/functional:515:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__functional/boyer_moore_searcher.h:26:
> ~/llvm/inst/bin/../include/c++/v1/vector:834:62: error: arithmetic on a pointer to an incomplete type 'FilterEntry'
> __alloc_traits::destroy(__alloc(), std::__to_address(--__soon_to_be_end));
> ^ ~~~~~~~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/vector:828:29: note: in instantiation of member function 'std::vector<FilterEntry>::__base_destruct_at_end' requested here
> void __clear() _NOEXCEPT {__base_destruct_at_end(this->__begin_);}
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:433:9: note: in instantiation of member function 'std::vector<FilterEntry>::__clear' requested here
> __clear();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:49:5: note: in instantiation of member function 'std::vector<FilterEntry>::~vector' requested here
> delete __ptr;
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<std::vector<FilterEntry>>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:86:19: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::~unique_ptr' requested here
> SalGtkFilePicker::SalGtkFilePicker( const uno::Reference< uno::XComponentContext >& xContext ) :
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.hxx:38:8: note: forward declaration of 'FilterEntry'
> struct FilterEntry;
> ^
> In file included from vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:28:
> In file included from workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/awt/SystemDependentXWindow.hpp:8:
> In file included from include/com/sun/star/uno/Type.hxx:29:
> In file included from ~/llvm/inst/bin/../include/c++/v1/ostream:169:
> In file included from ~/llvm/inst/bin/../include/c++/v1/bitset:129:
> In file included from ~/llvm/inst/bin/../include/c++/v1/string:548:
> ~/llvm/inst/bin/../include/c++/v1/__memory/allocator.h:128:58: error: invalid application of 'sizeof' to an incomplete type 'FilterEntry'
> _VSTD::__libcpp_deallocate((void*)__p, __n * sizeof(_Tp), _LIBCPP_ALIGNOF(_Tp));
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/allocator_traits.h:282:13: note: in instantiation of member function 'std::allocator<FilterEntry>::deallocate' requested here
> __a.deallocate(__p, __n);
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:434:25: note: in instantiation of member function 'std::allocator_traits<std::allocator<FilterEntry>>::deallocate' requested here
> __alloc_traits::deallocate(__alloc(), this->__begin_, capacity());
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:49:5: note: in instantiation of member function 'std::vector<FilterEntry>::~vector' requested here
> delete __ptr;
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<std::vector<FilterEntry>>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.cxx:86:19: note: in instantiation of member function 'std::unique_ptr<std::vector<FilterEntry>>::~unique_ptr' requested here
> SalGtkFilePicker::SalGtkFilePicker( const uno::Reference< uno::XComponentContext >& xContext ) :
> ^
> vcl/unx/gtk3/fpicker/SalGtkFilePicker.hxx:38:8: note: forward declaration of 'FilterEntry'
> struct FilterEntry;
> ^
Change-Id: I6f76dc24b12214eda75d3a5bb91a0fe120e38880
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141822
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from vcl/unx/gtk3/gtkinst.cxx:12:
> In file included from ~/llvm/inst/bin/../include/c++/v1/deque:181:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type '(anonymous namespace)::IMHandler'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<(anonymous namespace)::IMHandler>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<(anonymous namespace)::IMHandler>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/unx/gtk3/gtkinst.cxx:18108:5: note: in instantiation of member function 'std::unique_ptr<(anonymous namespace)::IMHandler>::~unique_ptr' requested here
> GtkInstanceDrawingArea(GtkDrawingArea* pDrawingArea, GtkInstanceBuilder* pBuilder, a11yref xA11y, bool bTakeOwnership)
> ^
> vcl/unx/gtk3/gtkinst.cxx:17947:7: note: forward declaration of '(anonymous namespace)::IMHandler'
> class IMHandler;
> ^
Change-Id: I555fc974762ba75f28705a3c4673956db275009f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141823
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from vcl/source/app/salvtables.cxx:26:
> In file included from workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/awt/XWindow.hpp:6:
> In file included from workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/awt/XWindow.hdl:13:
> In file included from workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/lang/XComponent.hdl:7:
> In file included from workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hdl:6:
> In file included from include/com/sun/star/uno/Any.h:30:
> In file included from include/rtl/ustring.hxx:34:
> In file included from ~/llvm/inst/bin/../include/c++/v1/ostream:168:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'SalFlashAttention'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<SalFlashAttention>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<SalFlashAttention>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> vcl/source/app/salvtables.cxx:292:20: note: in instantiation of member function 'std::unique_ptr<SalFlashAttention>::~unique_ptr' requested here
> SalInstanceWidget::SalInstanceWidget(vcl::Window* pWidget, SalInstanceBuilder* pBuilder,
> ^
> vcl/inc/salvtables.hxx:172:7: note: forward declaration of 'SalFlashAttention'
> class SalFlashAttention;
> ^
Change-Id: I49523c8db5b3fdd4dc5614fdb5c6f8ced73f5eca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141821
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from starmath/source/ElementsDockingWindow.cxx:20:
> In file included from starmath/inc/ElementsDockingWindow.hxx:22:
> In file included from include/sfx2/dockwin.hxx:22:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'ElementData'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<ElementData>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<ElementData>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:64:13: note: in instantiation of member function 'std::unique_ptr<ElementData>::~unique_ptr' requested here
> __loc->~_Tp();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:89:12: note: in instantiation of function template specialization 'std::__destroy_at<std::unique_ptr<ElementData>, 0>' requested here
> _VSTD::__destroy_at(__loc);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/allocator_traits.h:317:16: note: in instantiation of function template specialization 'std::destroy_at<std::unique_ptr<ElementData>, 0>' requested here
> _VSTD::destroy_at(__p);
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:834:25: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<std::unique_ptr<ElementData>>>::destroy<std::unique_ptr<ElementData>, void, void>' requested here
> __alloc_traits::destroy(__alloc(), std::__to_address(--__soon_to_be_end));
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:828:29: note: in instantiation of member function 'std::vector<std::unique_ptr<ElementData>>::__base_destruct_at_end' requested here
> void __clear() _NOEXCEPT {__base_destruct_at_end(this->__begin_);}
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:433:9: note: in instantiation of member function 'std::vector<std::unique_ptr<ElementData>>::__clear' requested here
> __clear();
> ^
> starmath/source/ElementsDockingWindow.cxx:455:20: note: in instantiation of member function 'std::vector<std::unique_ptr<ElementData>>::~vector' requested here
> SmElementsControl::SmElementsControl(std::unique_ptr<weld::IconView> pIconView)
> ^
> starmath/inc/ElementsDockingWindow.hxx:35:8: note: forward declaration of 'ElementData'
> struct ElementData;
> ^
Change-Id: Iaae76ed5e59d04da32b468a69052ef305ca8005a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141819
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from sc/source/ui/dbgui/dbnamdlg.cxx:20:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type '(anonymous namespace)::DBSaveData'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<(anonymous namespace)::DBSaveData>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<(anonymous namespace)::DBSaveData>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> sc/source/ui/dbgui/dbnamdlg.cxx:46:36: note: in instantiation of member function 'std::unique_ptr<(anonymous namespace)::DBSaveData>::~unique_ptr' requested here
> static std::unique_ptr<DBSaveData> xSaveObj;
> ^
> sc/source/ui/dbgui/dbnamdlg.cxx:42:7: note: forward declaration of '(anonymous namespace)::DBSaveData'
> class DBSaveData;
> ^
Change-Id: I65850c11a42886484dfbfbd4566ad71486337bc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141816
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from sfx2/source/dialog/StyleList.cxx:20:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'TreeViewDropTarget'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<TreeViewDropTarget>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<TreeViewDropTarget>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> sfx2/source/dialog/StyleList.cxx:72:12: note: in instantiation of member function 'std::unique_ptr<TreeViewDropTarget>::~unique_ptr' requested here
> StyleList::StyleList(weld::Builder* pBuilder, SfxBindings* pBindings,
> ^
> sfx2/source/inc/StyleList.hxx:53:7: note: forward declaration of 'TreeViewDropTarget'
> class TreeViewDropTarget;
> ^
Change-Id: I30c0c21a7366a9f45d8b4ce7c61270dac804c0b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141817
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from workdir/UnpackedTarball/skia/src/sksl/dsl/DSLFunction.cpp:8:
> In file included from workdir/UnpackedTarball/skia/include/sksl/DSLFunction.h:11:
> In file included from workdir/UnpackedTarball/skia/include/private/SkSLDefines.h:14:
> In file included from workdir/UnpackedTarball/skia/include/private/SkTArray.h:16:
> In file included from workdir/UnpackedTarball/skia/include/private/SkTemplates.h:18:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'SkSL::Expression'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<SkSL::Expression>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<SkSL::Expression>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> workdir/UnpackedTarball/skia/include/sksl/DSLFunction.h:100:43: note: in instantiation of member function 'std::unique_ptr<SkSL::Expression>::~unique_ptr' requested here
> args.push_back(DSLExpression(var).release());
> ^
> workdir/UnpackedTarball/skia/include/private/SkSLDefines.h:21:7: note: forward declaration of 'SkSL::Expression'
> class Expression;
> ^
and
> In file included from workdir/UnpackedTarball/skia/src/sksl/dsl/DSLVar.cpp:8:
> In file included from workdir/UnpackedTarball/skia/include/sksl/DSLVar.h:11:
> In file included from workdir/UnpackedTarball/skia/include/sksl/DSLExpression.h:11:
> In file included from workdir/UnpackedTarball/skia/include/private/SkTArray.h:16:
> In file included from workdir/UnpackedTarball/skia/include/private/SkTemplates.h:18:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'SkSL::Statement'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<SkSL::Statement>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<SkSL::Statement>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> workdir/UnpackedTarball/skia/include/sksl/DSLVar.h:38:5: note: in instantiation of member function 'std::unique_ptr<SkSL::Statement>::~unique_ptr' requested here
> DSLVarBase() : fType(kVoid_Type), fDeclared(true) {}
> ^
> workdir/UnpackedTarball/skia/include/private/SkSLDefines.h:22:7: note: forward declaration of 'SkSL::Statement'
> class Statement;
> ^
and
> In file included from workdir/UnpackedTarball/skia/src/gpu/ganesh/effects/GrBlendFragmentProcessor.cpp:8:
> In file included from workdir/UnpackedTarball/skia/src/gpu/ganesh/effects/GrBlendFragmentProcessor.h:12:
> In file included from workdir/UnpackedTarball/skia/include/core/SkRefCnt.h:16:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'GrFragmentProcessor'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<GrFragmentProcessor>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<GrFragmentProcessor>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> workdir/UnpackedTarball/skia/src/gpu/ganesh/effects/GrBlendFragmentProcessor.h:36:17: note: in instantiation of member function 'std::unique_ptr<GrFragmentProcessor>::~unique_ptr' requested here
> return Make(std::move(src), std::move(dst), mode, /*shareBlendLogic=*/false);
> ^
> workdir/UnpackedTarball/skia/src/gpu/ganesh/effects/GrBlendFragmentProcessor.h:14:7: note: forward declaration of 'GrFragmentProcessor'
> class GrFragmentProcessor;
> ^
Change-Id: I47f7280af3de7ed7b1915d4e5d2f7b52e4f26a9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141815
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from workdir/UnpackedTarball/pdfium/core/fxcodec/jbig2/JBig2_SymbolDict.cpp:7:
> In file included from workdir/UnpackedTarball/pdfium/core/fxcodec/jbig2/JBig2_SymbolDict.h:10:
> In file included from ~/llvm/inst/bin/../include/c++/v1/memory:881:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/shared_ptr.h:30:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'CJBig2_Image'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<CJBig2_Image>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<CJBig2_Image>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:64:13: note: in instantiation of member function 'std::unique_ptr<CJBig2_Image>::~unique_ptr' requested here
> __loc->~_Tp();
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/construct_at.h:89:12: note: in instantiation of function template specialization 'std::__destroy_at<std::unique_ptr<CJBig2_Image>, 0>' requested here
> _VSTD::__destroy_at(__loc);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/allocator_traits.h:317:16: note: in instantiation of function template specialization 'std::destroy_at<std::unique_ptr<CJBig2_Image>, 0>' requested here
> _VSTD::destroy_at(__p);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__split_buffer:304:25: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<std::unique_ptr<CJBig2_Image>>>::destroy<std::unique_ptr<CJBig2_Image>, void, void>' requested here
> __alloc_traits::destroy(__alloc(), _VSTD::__to_address(--__end_));
> ^
> ~/llvm/inst/bin/../include/c++/v1/__split_buffer:145:10: note: in instantiation of member function 'std::__split_buffer<std::unique_ptr<CJBig2_Image>, std::allocator<std::unique_ptr<CJBig2_Image>> &>::__destruct_at_end' requested here
> {__destruct_at_end(__new_last, false_type());}
> ^
> ~/llvm/inst/bin/../include/c++/v1/__split_buffer:103:10: note: in instantiation of member function 'std::__split_buffer<std::unique_ptr<CJBig2_Image>, std::allocator<std::unique_ptr<CJBig2_Image>> &>::__destruct_at_end' requested here
> {__destruct_at_end(__begin_);}
> ^
> ~/llvm/inst/bin/../include/c++/v1/__split_buffer:361:5: note: in instantiation of member function 'std::__split_buffer<std::unique_ptr<CJBig2_Image>, std::allocator<std::unique_ptr<CJBig2_Image>> &>::clear' requested here
> clear();
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:1536:49: note: in instantiation of member function 'std::__split_buffer<std::unique_ptr<CJBig2_Image>, std::allocator<std::unique_ptr<CJBig2_Image>> &>::~__split_buffer' requested here
> __split_buffer<value_type, allocator_type&> __v(__recommend(size() + 1), size(), __a);
> ^
> ~/llvm/inst/bin/../include/c++/v1/vector:1568:9: note: in instantiation of function template specialization 'std::vector<std::unique_ptr<CJBig2_Image>>::__push_back_slow_path<std::unique_ptr<CJBig2_Image>>' requested here
> __push_back_slow_path(std::move(__x));
> ^
> workdir/UnpackedTarball/pdfium/core/fxcodec/jbig2/JBig2_SymbolDict.h:26:16: note: in instantiation of member function 'std::vector<std::unique_ptr<CJBig2_Image>>::push_back' requested here
> m_SDEXSYMS.push_back(std::move(image));
> ^
> workdir/UnpackedTarball/pdfium/core/fxcodec/jbig2/JBig2_SymbolDict.h:16:7: note: forward declaration of 'CJBig2_Image'
> class CJBig2_Image;
> ^
Change-Id: Ibaeb72eefdd58ca39ffa6bb8f6c5d7088ce51ab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141812
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from cui/source/dialogs/cuihyperdlg.cxx:23:
> In file included from include/comphelper/lok.hxx:14:
> In file included from include/rtl/ustring.hxx:34:
> In file included from ~/llvm/inst/bin/../include/c++/v1/ostream:168:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'IconChoicePage'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<IconChoicePage>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<IconChoicePage>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> cui/source/inc/iconcdlg.hxx:43:5: note: in instantiation of member function 'std::unique_ptr<IconChoicePage>::~unique_ptr' requested here
> IconChoicePageData(OString aId, std::unique_ptr<IconChoicePage> xInPage)
> ^
> cui/source/inc/iconcdlg.hxx:28:7: note: forward declaration of 'IconChoicePage'
> class IconChoicePage;
> ^
Change-Id: I789c85e0661969679c88fea1dfc7a65475fb3037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141811
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that hits at least when building with Clang and --with-latest-c++ against
recent libc++ or MSVC standard library (where C++20 and esp. C++23 made more and
more class template member functions constexpr). My understanding is that there
is some leeway at what point a compiler should instantiate such function
specializations, and Clang decides to instantiate constexpr ones early (cf.
<https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511>
"C++11 half of r147023: In C++11, additionally eagerly instantiate:" and its "Do
not defer instantiations of constexpr functions" comment, and the discussion at
<https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129>).
> In file included from basic/source/comp/codegen.cxx:21:
> In file included from include/basic/sberrors.hxx:23:
> In file included from include/vcl/errcode.hxx:23:
> In file included from include/rtl/ustring.hxx:34:
> In file included from ~/llvm/inst/bin/../include/c++/v1/ostream:168:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:47:19: error: invalid application of 'sizeof' to an incomplete type 'SbiExprList'
> static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:281:7: note: in instantiation of member function 'std::default_delete<SbiExprList>::operator()' requested here
> __ptr_.second()(__tmp);
> ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:247:75: note: in instantiation of member function 'std::unique_ptr<SbiExprList>::reset' requested here
> _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> ^
> basic/source/inc/expr.hxx:118:66: note: in instantiation of member function 'std::unique_ptr<SbiExprList>::~unique_ptr' requested here
> SbiExprNode( const SbiSymDef&, SbxDataType, SbiExprListPtr = nullptr );
> ^
> basic/source/inc/expr.hxx:30:7: note: forward declaration of 'SbiExprList'
> class SbiExprList;
> ^
Change-Id: I3bde85164ae6b829b7c24d9645fd412ed3fd815d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141810
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in code recently introduced in 0bf8a781ff
"related tdf#151548 sw: KEY_DOWN access to FieldmarkWithDropDownButton", which
at least GCC 12 and recent GCC 13 trunk in an --enable-dbgutil
--enable-optimized --enable-werror build diagnosed as
> sw/source/core/crsr/bookmark.cxx: In member function ‘void sw::mark::FieldmarkWithDropDownButton::LaunchPopup()’:
> sw/source/core/crsr/bookmark.cxx:669:30: error: ‘this’ pointer is null [-Werror=nonnull]
> 669 | m_pButton->Invalidate();
> | ~~~~~~~~~~~~~~~~~~~~~^~
> cc1plus: all warnings being treated as errors
Change-Id: I1e6d7e7e0244259674d41edff4c07a2de2b74bdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141791
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...not just for Windows. This information is occasionally useful also on other
platforms that can run executables targeting different CPU architectures (like
Linux x86 and x86-64, or macOS Aarch64 and x86-64), e.g. when trying to track
down why a bug reporter's system doesn't find a JRE matching the architecture of
their LibreOffice installation.
For simplicity, use the existing _ARCH bootstrap variable, even if its values
differ from the hardcoded "x64" and "x86" that have been used here so far.
Change-Id: I76b40dd044397bf19e014d8a56d0314f455bc8ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141768
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Update helpcontent2 from branch 'master'
to 5ee668393aaea0357f582223f50af63e2d2df727
- Fix helpcontent2 build failure
> [PKG] helpcontent2_html_media_lang_en-US
> /usr/bin/cp: cannot stat '/.../helpcontent2/source/media/screenshots/modules/swriter/ui/watermarkdialog/WatermarkDialog.png': No such file or directory
> make[1]: *** [/.../solenv/gbuild/Package.mk:35: /.../instdir/help/media/screenshots/modules/swriter/ui/watermarkdialog/WatermarkDialog.png] Error 1
by putting back a file (erroneously?) removed by
4f5ecc07647d1c01858b24f96683e6061ef49c02 "Reduce Writer screenshots to
valid Help locales"
Change-Id: Ib32426d14ff0bdd74885b8d78f3af271afc25d21
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/141654
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
f240f073d2 "Related: tdf#102308 sw: ignore seconds
when combining redlines" had just naively cut off the seconds for comparison,
but which apparently gave unexpected results when the two dates are sufficiently
close but lie on different sides of a minute tick:
Autocorrection-related unit tests like CppunitTest_sw_uiwriter6
CPPUNIT_TEST_NAME=testRedlineAutoCorrect2::TestBody sporadically failed to
execute some autocorrection, as in
> uiwriter6.cxx:1436:Assertion
> Test name: testRedlineAutoCorrect2::TestBody
> equality assertion failed
> - Expected: Lorem,... Lorem,…
> - Actual : Lorem,... Lorem,...
What happened there in testRedlineAutoCorrect2
(sw/qa/extras/uiwriter/uiwriter6.cxx) is that each emulateTyping consecutive
simulated character input should extend the current redline range, by hitting
the
> // Merge if applicable?
> if( (( SwComparePosition::Behind == eCmpPos &&
> IsPrevPos( *pREnd, *pStt ) ) ||
> ( SwComparePosition::CollideStart == eCmpPos ) ||
> ( SwComparePosition::OverlapBehind == eCmpPos ) ) &&
> pRedl->CanCombine( *pNewRedl ) &&
> ( n+1 >= maRedlineTable.size() ||
> ( *maRedlineTable[ n+1 ]->Start() >= *pEnd &&
> *maRedlineTable[ n+1 ]->Start() != *pREnd ) ) )
branch in DocumentRedlineManager::AppendRedline
(sw/source/core/doc/DocumentRedlineManager.cxx). However, when that happened to
fail on a minute tick boundary because its
> pRedl->CanCombine( *pNewRedl ) &&
part was false, we would end up with split redline ranges, and
SwAutoCorrDoc::ChgAutoCorrWord (sw/source/core/edit/acorrect.cxx) would not
execute the autocorrection replacement across those split ranges due to its
> // don't replace, if a redline starts or ends within the original text
code. (One way of making that test fail reproducibly would be with some
> diff --git a/sw/qa/extras/uiwriter/uiwriter6.cxx b/sw/qa/extras/uiwriter/uiwriter6.cxx
> index 0159c5bf07ed..8716c6a09882 100644
> --- a/sw/qa/extras/uiwriter/uiwriter6.cxx
> +++ b/sw/qa/extras/uiwriter/uiwriter6.cxx
> @@ -7,6 +7,10 @@
> * file, You can obtain one at http://mozilla.org/MPL/2.0/.
> */
>
> +#include <sal/config.h>
> +
> +#include <chrono>
> +
> #include <com/sun/star/drawing/FillStyle.hpp>
> #include <swmodeltestbase.hxx>
> #include <cntfrm.hxx>
> @@ -33,6 +37,7 @@
> #include <com/sun/star/text/XTextViewCursorSupplier.hpp>
> #include <com/sun/star/view/XSelectionSupplier.hpp>
> #include <o3tl/cppunittraitshelper.hxx>
> +#include <osl/thread.hxx>
> #include <swdtflvr.hxx>
> #include <comphelper/propertysequence.hxx>
> #include <LibreOfficeKit/LibreOfficeKitEnums.h>
> @@ -1431,7 +1436,9 @@ CPPUNIT_TEST_FIXTURE(SwUiWriterTest6, testRedlineAutoCorrect2)
> CPPUNIT_ASSERT_EQUAL(sReplaced, getParagraph(1)->getString());
>
> // Continue it:
> - emulateTyping(rXTextDocument, u"Lorem,... ");
> + emulateTyping(rXTextDocument, u"Lorem,...");
> + osl::Thread::wait(std::chrono::seconds(70));
> + emulateTyping(rXTextDocument, u" ");
> sReplaced = u"Lorem,... Lorem,… ";
> CPPUNIT_ASSERT_EQUAL(sReplaced, getParagraph(1)->getString());
> }
patch.)
So at least improve SwRedlineData::CanCombine to properly check for a date delta
of <= 1 minute. However, that still leaves those tests prone to sporadic
failures (even though less likely), if they get delayed for a sufficient amount
of time in strategically unfortunate places. Ideally, those
autocorrection-related tests (which appear to be the ones in
sw/qa/extras/uiwriter/uiwriter6.cxx using emulateTyping) would run with
redlining turned off, but many of them explicitly enable redlining, presumably
for a reason.
With that change, UITest_writer_tests started to fail with
> FAIL: test_tdf135018 (trackedChanges.trackedchanges)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sw/qa/uitest/writer_tests/trackedChanges.py", line 203, in test_tdf135018
> self.assertEqual(147, len(changesList.getChildren()))
> AssertionError: 147 != 111
in a test introduced with b6ab2330d9 "tdf#135018:
sw: Add UItest". That sw/qa/uitest/data/tdf135018.odt's content.xml contains
147 <text:tracked-changes> <dc:date> elements ranging from 2020-07-11T10:29:12
to 2020-07-21T11:50:32, and apparently some adjacent changes with sufficiently
close dates now started to get combined when executing
.uno:AcceptTrackedChanges.
Change-Id: I1d3453bbf5b0206c080bd3421d525e6b8351f2b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141653
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...similar to f6be6cd82b "external/firebird:
Missing include in configure check" and 7e1ff1cee5
"external/firebird: Implicit int in configure check". With recent Clang on
Linux it had still failed to detected
> configure:20511: checking for working sem_init()
[...]
> conftest.c:166:2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
> main () {
> ^
> int
> conftest.c:168:3: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> exit(sem_init(&s,0,0));
> ^
> conftest.c:168:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
and
> configure:21256: checking for native large file support
[...]
> conftest.c:167:5: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
> main () {
> ^
> int
> conftest.c:168:5: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> exit(!(sizeof(off_t) == 8));
> ^
> conftest.c:168:5: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
And at least the former, which erroneously suppressed setting WORKING_SEM_INIT,
sporadically caused CppunitTest_dbaccess_hsql_binary_import to SIGABRT for me at
> #10 0x00007f087fce37fc in __GI_abort ()
> #11 0x00007f085a7e32e8 in Firebird::system_call_failed::system_call_failed(char const*, int) (this=0x55fbb11e5650, syscall=0x7f085a19ac06 "sem_open", error_code=17) at workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp:244
> #12 0x00007f085a7e33ba in Firebird::system_call_failed::raise(char const*) (syscall=0x7f085a19ac06 "sem_open") at workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp:255
> #13 0x00007f085a81ff4e in Firebird::SignalSafeSemaphore::init() (this=0x55fbb1268c80) at workdir/UnpackedTarball/firebird/src/common/classes/semaphore.cpp:138
> #14 0x00007f085a38ee85 in Firebird::SignalSafeSemaphore::SignalSafeSemaphore() (this=0x55fbb1268c80) at workdir/UnpackedTarball/firebird/src/common/classes/semaphore.h:156
> #15 0x00007f085a38c931 in (anonymous namespace)::MappingIpc::MappingIpc(Firebird::MemoryPool&) (this=0x55fbb1268bf0) at workdir/UnpackedTarball/firebird/src/jrd/Mapping.cpp:602
> #16 0x00007f085a38176b in Firebird::GlobalPtr<(anonymous namespace)::MappingIpc, (Firebird::InstanceControl::DtorPriority)2>::GlobalPtr() (this=0x7f085a93e780 <(anonymous namespace)::mappingIpc>) at workdir/UnpackedTarball/firebird/src/common/classes/init.h:143
> #17 0x00007f085a38d270 in __cxx_global_var_init.15(void) () at workdir/UnpackedTarball/firebird/src/jrd/Mapping.cpp:901
[...]
> #32 0x00007f085bb37626 in ModuleLoader::loadModule(long*, Firebird::StringBase<Firebird::PathNameComparator> const&) (status=0x7ffd9f8b42a0, modPath=...) at workdir/UnpackedTarball/firebird/src/common/os/posix/mod_loader.cpp:95
[...]
Change-Id: I082be878d95a020a7c419d6852614b711754cc23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141549
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where ScTypeStrData::LessCase(In)sensitive is implemented in terms of
ScGlobal::Get(Case)Collator().compareString. And that apparently implements
only a strict weak ordering (in the C++ Standard's meaning of the term) rather
than a strict total ordering (i.e., sorts different strings into equivalence
classes, e.g., ScGlobal::GetCollator().compareString("guet", "guͤt") returns 0).
With a randomizing debug-mode libc++, tests recently added to UITest_autofilter
failed for me with
> FAIL: test_tdf123095 (autofilterBugs.autofilter)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sc/qa/uitest/autofilter/autofilterBugs.py", line 45, in test_tdf123095
> self.assertEqual(get_state_as_dict(xTreeList.getChild("0"))["Text"], "乙二醇(进口料件)")
> AssertionError: '乙二醇（进口料件）' != '乙二醇(进口料件)'
> - 乙二醇（进口料件）
> ? ^ ^
> + 乙二醇(进口料件)
> ? ^ ^
when _LIBCPP_DEBUG_RANDOMIZE_UNSPECIFIED_STABILITY_SEED is e.g. 140434132192856
and
> FAIL: test_tdf125363 (autofilterBugs.autofilter)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sc/qa/uitest/autofilter/autofilterBugs.py", line 69, in test_tdf125363
> self.assertEqual(get_state_as_dict(xTreeList.getChild("0"))["Text"], "guet")
> AssertionError: 'guͤt' != 'guet'
> - guͤt
> ? ^
> + guet
> ? ^
when _LIBCPP_DEBUG_RANDOMIZE_UNSPECIFIED_STABILITY_SEED is e.g. 139927542230616.
(Those tests only required the !bCaseSens case to be stable_sort'ed, but it
looks plausible that the bCaseSens case would suffer from the same issue, so
lets stable_sort that one too.)
Change-Id: I860ae7b58f09c85da82fca99a2962f12d70d2202
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141548
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With the Windows display language set to "Portuguès (Brasil)" (and the
corresponding Visual Studio language pack installed), configure.ac detected
SHOWINCLUDES_PREFIX to have the value "Observação: incluindo arquivo:" in UTF-8
(i.e., with bytes ... C3 A7 C3 A3 ...). However, for whatever reason
filter-showIncludes.awk apparently didn't manage to match the input it receives
against the value of that environment variable, and the Cygwin terminal
contained output lines starting with either
> Observa□ao: incluindo arquivo:
(with toplevel plain `make`, plain `make` in a module, and `make -O` in a
module) or
> Observaçao: incluindo arquivo:
(with toplevel `make -O`). (Note how "ç" is either garbled as "□" or shown
correctly, and "ã" is always shown as plain "a".) It's not quite clear to me
where exactly this garbling happens, and why the behavior is apparently
different in configure.ac vs. make.
The most reliable way to avoid these issues altogether is to force MSVC to emit
English diagnostics, via VSLANG=1033, as explained at
<https://stackoverflow.com/questions/2286216/how-to-change-msbuild-error-message-language>.
(I didn't find any official documentation of that environment variable on MSDN
though. Thanks to Mike Kaganski for providing that Stack Overflow link.)
dfbce2a556 "gbuild: try to run
filter-showIncludes.awk in C locale" had started to call that AWK script with
LC_ALL=C (and subsequent commits had copied that LC_ALL=C in calls to similar
AWK scripts). But that appears to neither be sufficient (see above) nor
necessary now, so I removed all those LC_ALL=C settings. (There is a gawk
--characters-as-bytes option, but trying that out didn't make a difference for
this issue.)
clang-cl doesn't support VSLANG, nor does it generate localized diagnostics in
the first place, but lets consistently add VSLANG=1033 when determining
LO_CLANG_SHOWINCLUDES_PREFIX in configure.ac, too. (The way VSLANG=1033 is set
in gb_CObject__compiler in com_MSC_class.mk, it affects all kinds of MSVC and
clang-cl invocations, whether or not they actually honour that environment
variable.)
Change-Id: I52d0e842d200ed256a44d6cc5de1b3868c0acc71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141524
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
That check had been added with 32bc8ddbf3
"tdf#94716 allow Oracle's JDK to be used on OS X 10.10 and 10.11", back at a
time when there was substantial trouble with installations of Apple's own Java
and Oracle JREs. One consequence of that commit and its
JvmfwkUtil_isLoadableJVM check was that on macOS we only supported JDKs (with a
surrounding Contents directory containing an appropriate Info.plist files), not
plain JREs (cf. <https://wiki.documentfoundation.org/ReleaseNotes/5.1#macOS>
"Prior work arounds of having both an Apple JRE 6 and an Oracle JRE 8 are no
longer sufficient. Use of the JDK is now hard coded, see tdf#74877, tdf#94716
and core commit 32bc8ddbf335dd26019edcf12758643b4cff9913.")
However, Apple's own Java is long since deprecated (cf.
<https://support.apple.com/en-us/HT204036> "You can also download legacy Java SE
6 from Apple if you’re using an app that specifically requires this unsupported,
out-of-date version."), and presumably of no practical concern at least on
contemporary Aarch64-based macOS.
And there is e.g. SDKMAN! (<https://sdkman.io/>), which installs JDKs in a way
that they are not surrounded by Contents directories containing appropriate
Info.plist files, so JvmfwkUtil_isLoadableJVM returned false for them and you
couldn't add them on the LibreOffice Advanced Options tab.
So at least for Aarch64-based macOS, drop that presumably-legacy
JvmfwkUtil_isLoadableJVM check (but keep it for x86-64--based macOS at least for
now, just to be safe). (That implies that for Aarch64-based macOS, it should
now work again to also use plain JREs.)
Change-Id: I3bcbb3c14e3a9e9dde39fd6f4572b632e05df9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141508
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that the Python script provider, based on those DateModified values, will
reload a script embedded in a document after that script has (programmatically)
been modified.
As long as a stream content in a tdoc document has not been modified, it will
report a default-initialized (all zero) DateModified. Only when the stream has
been modified will that be changed to the current date. While that might not be
the most beautiful implementation, it at least gets the job done of fixing
tdf#105609 "Python script provider does not reload modified embedded scripts".
(The DateModified values cannot be stored directly in the tdoc_ucp::Content
instances, as those are thrown away and recreated on demand. So they needed to
be stored more persistently at the tdoc_ucp::OfficeDocumentsManager.)
Change-Id: Iee809960e1a1bc40961f0df2b3729e58b75e6028
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141491
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 3d236177be "Deduplicate
O(U)StringConcatenation" changed OStringConcat and OUStringConcat into aliases
(so they will get looked through by loplugin::TypeCheck::Struct's use of
getAs<clang::RecordType> in compilerplugins/clang/check.hxx), but apparently
forgot to drop their respective checks here. (That the then-added check for
StringConcat works as intended is verified by
compilerplugins/clang/test/stringview.cxx, btw.)
Change-Id: I3f8e26998d0a55704f0433a818493ef541fd05eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141370
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 3d236177be "Deduplicate
O(U)StringConcatenation" changed OStringConcat and OUStringConcat into aliases
(so they can never show up here in a "getUnqualifiedDesugareType"), but
apparently forgot to drop their respective checks here. (That the then-added
check for StringConcat works as intended is verified by
compilerplugins/clang/test/stringadd.cxx, btw.)
Change-Id: I2b589d977dbf2a384348cb7ee62acce30031ccec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141364
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after af2879e434 "Deduplicate stringconcat
more" changed the *StringNumberBase::toAsciiUperCase return typr from
O[U]StringNumber to the underlying StringNumberBase. (And where that commit had
added some odd check for a non-existing "StringNumber" type to
compilerplugins/clang/stringconcatauto.cxx, presumably in error.)
Change-Id: I622e6ae30fcec8f081c978eaf67ffb716a10ee4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
c79212479f "Fix a misuse of two-argument std
string_view rfind" found that e.g. in Writer "Tools - Macros - Organize Macros -
Basic...", in "Macro From" select "My Macros - Standard - Module1" and in
"Existing Macros in: Module 1" select "Main", then "Assign..." had apparently
rotten over time and brought up the "Customize" dialog's default "Menus" tab.
With this fix, it now brings up the "Customize" dialog's "Keyboard" tab, in the
"Category" tree list selects the appropriate "Module1" line, and in the
"Function" list shows all the corresponding functions (just "Main" in this
case).
It doesn't yet select the appropriate line ("Main") in the "Function" list,
though. That apparently needs further fixing.
Change-Id: Ia5b9ef88d29e01f4f5e22ce3aec20f5fc22b5d45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141303
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where at least my recent Clang 16 trunk build now started to fail after
af2879e434 "Deduplicate stringconcat more" with
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/stringview.cxx Line 171 (directive at compilerplugins/clang/test/stringview.cxx:170): instead of an '{{(rtl::)?}}OString' constructed from a 'OStringConcat<rtl::OString, rtl::OString>' (aka 'StringConcat<char, rtl::OString, rtl::OString>'), pass a 'std::string_view' via 'rtl::Concat2View' [loplugin:stringview]
> File compilerplugins/clang/test/stringview.cxx Line 196 (directive at compilerplugins/clang/test/stringview.cxx:195): instead of an '{{(rtl::)?}}OUString' constructed from a 'OUStringConcat<rtl::OUString, rtl::OUString>' (aka 'StringConcat<char16_t, rtl::OUString, rtl::OUString>'), pass a 'std::u16string_view' via 'rtl::Concat2View' [loplugin:stringview]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/stringview.cxx Line 171: instead of an 'OString' constructed from a 'OStringConcat<OString, OString>' (aka 'StringConcat<char, rtl::OString, rtl::OString>'), pass a 'std::string_view' via 'rtl::Concat2View' [loplugin:stringview]
> File compilerplugins/clang/test/stringview.cxx Line 196: instead of an 'OUString' constructed from a 'OUStringConcat<OUString, OUString>' (aka 'StringConcat<char16_t, rtl::OUString, rtl::OUString>'), pass a 'std::u16string_view' via 'rtl::Concat2View' [loplugin:stringview]
> 4 errors generated.
> make[1]: *** [solenv/gbuild/LinkTarget.mk:337: workdir/CxxObject/compilerplugins/clang/test/stringview.o] Error 1
Change-Id: I0b8c7d4a012c40c2c2c3cc8a9e55c52f45e8cfc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After 001de7e21d, CppunitTest_sw_ww8export
CPPUNIT_TEST_NAME=testTdf94386::TestBody started to fail with
> svl/source/items/itemset.cxx:176:42: runtime error: member call on address 0x60400083cbd0 which does not point to an object of type 'SfxItemPool'
> 0x60400083cbd0: note: object has invalid vptr
> 00 00 00 00 b0 6e 02 00 00 00 00 00 00 00 00 00 be be be be 40 44 b1 05 e1 7f 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> invalid vptr
> #0 in SfxItemSet::~SfxItemSet() at svl/source/items/itemset.cxx:176:42
> #1 in testTdf94386::TestBody() at sw/qa/extras/ww8export/ww8export.cxx:1555:1
Change-Id: I6dff915866a4e7d1250b253e53061e5646aebf15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141253
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
...after the last use of that RawFontData got removed in
112d07027c "vcl: Use
PhysicalFontFace::GetRawFontData() for font embedding"
Change-Id: Id85eb39b6fd946da132d53ba937032f3c58b061d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141225
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as seen at least with --without-latest-c++ after
d0b2f5f65e "pdfium: drop not needed annot.patch.1"
during CppunitTest_sw_core_text,
> workdir/UnpackedTarball/pdfium/core/fxcrt/string_data_template.cpp:76:20: runtime error: null pointer passed as argument 2, which is declared to never be null
> /usr/include/string.h:44:28: note: nonnull attribute specified here
> #0 in fxcrt::StringDataTemplate<char>::CopyContents(char const*, unsigned long) at workdir/UnpackedTarball/pdfium/core/fxcrt/string_data_template.cpp:76:3
> #1 in fxcrt::ByteString::ByteString(fxcrt::StringViewTemplate<char>, fxcrt::StringViewTemplate<char>) at workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.cpp:160:12
> #2 in fxcrt::operator+(fxcrt::ByteString const&, fxcrt::ByteString const&) at workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.h:265:10
> #3 in CPDFSDK_AppStream::SetAsTextField(absl::optional<fxcrt::WideString>) at workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_appstream.cpp:1805:34
> #4 in CPDFSDK_Widget::ResetAppearance(absl::optional<fxcrt::WideString>, CPDFSDK_Widget::ValueChanged) at workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_widget.cpp:655:17
> #5 in CPDFSDK_PageView::NewAnnot(CPDF_Annot*) at workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_pageview.cpp:108:12
> #6 in CPDFSDK_PageView::LoadFXAnnots() at workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_pageview.cpp:566:45
> #7 in CPDFSDK_FormFillEnvironment::GetOrCreatePageView(IPDF_Page*) at workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_formfillenvironment.cpp:625:14
> #8 in (anonymous namespace)::FormHandleToPageView(fpdf_form_handle_t__*, fpdf_page_t__*) at workdir/UnpackedTarball/pdfium/fpdfsdk/fpdf_formfill.cpp:169:39
> #9 in FORM_OnAfterLoadPage at workdir/UnpackedTarball/pdfium/fpdfsdk/fpdf_formfill.cpp:730:37
> #10 in vcl::pdf::(anonymous namespace)::PDFiumPageImpl::onAfterLoadPage(vcl::pdf::PDFiumDocument*) at vcl/source/pdf/PDFiumLibrary.cxx:764:5
> #11 in testContentControlPDFFont::TestBody() at sw/qa/core/text/text.cxx:746:12
Change-Id: Iba73a9401eb10a8c03843dba038cd3a6eeeb0c4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141210
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> /Users/stephan/lo/core/vcl/quartz/ctfonts.cxx:255:33: error: loop index type 'unsigned int' is narrower than length type 'CFIndex' (aka 'long') [loplugin:loopvartoosmall]
> for (auto i = 0u; i < nTags; i++)
> ~~^~~~~~~
(and whatever the motivation in d7083fe6dd
"tdf#72456: Support font embedding on macOS" to use an unsigned 0u here)
Change-Id: I6a96dd2b2146c27d68a8a53daf3c2fe1f744738d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141201
Reviewed-by: خالد حسني <khaled@aliftype.com>
Tested-by: Jenkins
(<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html> "The
Equality Operator You Are Looking For"), as now implemented by Clang 16 trunk
since
<https://github.com/llvm/llvm-project/commit/38b9d313e6945804fffc654f849cfa05ba2c713d>
"[C++20][Clang] P2468R2 The Equality Operator You Are Looking For", and which
started to make my --with-latest-c++ build fail with
> workdir/UnpackedTarball/pdfium/fpdfsdk/cpdfsdk_interactiveform.cpp:189:22: error: invalid operands to binary expression ('const CPDF_Dictionary *' and 'RetainPtr<const CPDF_Object>')
> if (pAnnotDict == pDict)
> ~~~~~~~~~~ ^ ~~~~~
> workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.h:227:13: note: candidate function not viable: no known conversion from 'const CPDF_Dictionary *' to 'const char *' for 1st argument
> inline bool operator==(const char* lhs, const ByteString& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.h:227:13: note: candidate function (with reversed parameter order) not viable: no known conversion from 'const CPDF_Dictionary *' to 'const ByteString' for 1st argument
> workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.h:230:13: note: candidate function not viable: no known conversion from 'const CPDF_Dictionary *' to 'ByteStringView' (aka 'StringViewTemplate<char>') for 1st argument
> inline bool operator==(ByteStringView lhs, const ByteString& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.h:230:13: note: candidate function (with reversed parameter order) not viable: no known conversion from 'const CPDF_Dictionary *' to 'const ByteString' for 1st argument
> workdir/UnpackedTarball/pdfium/core/fxcrt/widestring.h:285:13: note: candidate function not viable: no known conversion from 'const CPDF_Dictionary *' to 'const wchar_t *' for 1st argument
> inline bool operator==(const wchar_t* lhs, const WideString& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/widestring.h:285:13: note: candidate function (with reversed parameter order) not viable: no known conversion from 'const CPDF_Dictionary *' to 'const WideString' for 1st argument
> workdir/UnpackedTarball/pdfium/core/fxcrt/widestring.h:288:13: note: candidate function not viable: no known conversion from 'const CPDF_Dictionary *' to 'WideStringView' (aka 'StringViewTemplate<wchar_t>') for 1st argument
> inline bool operator==(WideStringView lhs, const WideString& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/widestring.h:288:13: note: candidate function (with reversed parameter order) not viable: no known conversion from 'const CPDF_Dictionary *' to 'const WideString' for 1st argument
> workdir/UnpackedTarball/pdfium/core/fxge/cfx_color.h:61:13: note: candidate function not viable: no known conversion from 'const CPDF_Dictionary *' to 'const CFX_Color' for 1st argument
> inline bool operator==(const CFX_Color& c1, const CFX_Color& c2) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/string_view_template.h:277:13: note: candidate template ignored: could not match 'StringViewTemplate' against 'RetainPtr'
> inline bool operator==(const T* lhs, const StringViewTemplate<T>& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/string_view_template.h:277:13: note: candidate template ignored: could not match 'const T *' against 'RetainPtr<const CPDF_Object>'
> workdir/UnpackedTarball/pdfium/core/fxcrt/observed_ptr.h:98:13: note: candidate template ignored: could not match 'ObservedPtr' against 'RetainPtr'
> inline bool operator==(const U* lhs, const ObservedPtr<T>& rhs) {
> ^
> workdir/UnpackedTarball/pdfium/core/fxcrt/observed_ptr.h:98:13: note: candidate template ignored: could not match 'const U *' against 'RetainPtr<const CPDF_Object>'
Change-Id: Ibef9e5515dc466431741220adebec9c6e20850e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141154
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts the configmgr part of 0a7eac8576 "use
more string_view in accessibility..configmgr": All calls to Data::parseSegment
(either directly, or indirectly either via Access::getSubChild or via
parseSegment in partial.cxx) pass in an OUString path, and in some cases (see
below)
> *name = path.substr(index, i - index);
in Data::parseSegment reconstructs an OUString from the full path (i.e.,
index == 0 and i == path.size()). And I see no code that actually benefited
from the switch to string_view.
One example call stack for such an expensive reconstruction of an OUString from
full path is
> #0 in configmgr::Data::parseSegment(path=u"ooSetupSystemLocale", index=0, name=0x7ffff5299280, setElement=0x7ffff52992a0, templateName=0x7ffff52992b0) in core/configmgr/source/data.cxx
> #1 in configmgr::Access::getSubChild(this=0x619000028f80, path=u"ooSetupSystemLocale") in core/configmgr/source/access.cxx
> #2 in configmgr::Access::getByHierarchicalName(this=0x619000028f80, aName="ooSetupSystemLocale") in core/configmgr/source/access.cxx
> #3 in utl::ConfigItem::GetProperties(xHierarchyAccess=uno::Reference to (configmgr::RootAccess *) 0x619000028fb8, rNames=uno::Sequence of length 6 = {...}, bAllLocales=false) in core/unotools/source/config/configitem.cxx
> #4 in utl::ConfigItem::GetProperties(this=0x61100000cad0, rNames=uno::Sequence of length 6 = {...}) in core/unotools/source/config/configitem.cxx
> #5 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl(this=0x61100000cad0) in core/unotools/source/config/syslocaleoptions.cxx
[...]
Change-Id: I51127d82aea927dd9aaf374880c406dbafaddcde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140658
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by making it more resilient against varying screen sizes. On my 2560x1600
Windows laptop, three `make check` tests systematically failed, and apparently
all of them were caused by that larger-than-average screen (similar to what has
been detailed in the commit message of 3db6a93c55
"Compute a better GetDefaultCenterPos"):
* CppunitTest_sw_layoutwriter
> test/source/xmltesttools.cxx:191:testTdf134298::TestBody
> equality assertion failed
> - Expected: 2
> - Actual : 3
> - In <>, XPath '/root/page' number of nodes is incorrect
* CppunitTest_sw_ooxmlexport12
> sw/qa/extras/ooxmlexport/ooxmlexport12.cxx:526:testObjectCrossReference::TestBody
> equality assertion failed
> - Expected: Text 2
> - Actual : 2
* CppunitTest_sw_uiwriter2
> sw/qa/extras/uiwriter/uiwriter2.cxx:2702:testTdf122942::TestBody
> equality assertion failed
> - Expected: 2
> - Actual : 1
Those tests are all run with both SAL_USE_VCLPLUGIN=svp and --headless. But svp
is only present on Linux and is thus ignored on Windows. And --headless, while
preventing any windows from actually being shown, nevertheless uses the GUI code
to set up window sizes. So the idea here is to hack the Windows backend in
strategic places so that it uses "appropriate" window sizes in --headless mode
to make `make check` succeed.
The Linux svp backend has a single place in vcl/headless/svpframe.cxx where it
hardcodes the number of monitors to 1 and the screen size to 1024x768. However,
for the Windows backend, code determining and using those values is somewhat
spread, but it turned out that there is one strategic place in
ImplSalGetWorkArea that does what we want (without touching the reported number
of monitors at all), without (it appears) negatively affecting other scenarios.
(It appears that macOS, also not supporting an svp backend, is similarly
affected. But it looks harder there to come up with such a strategic place to
hardcode --headless window sizes, and at least my own macOS build's `make check`
is unaffected as I use a default scaled 1829x1080 screen resolution there
instead of the "raw" 3840x2160.)
Change-Id: I822241f81497b9f6bed8e9688eddbe7d798c6b34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140588
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Fix regressions introduced with 5edefc801f "use
more string_view in unotools". (Notably, misuses of two-argument std
string_view rfind are something to watch out for, see the commit message of
93e234c45c "Fix a misuse of two-argument std
string_view rfind" for details.)
* Bring the implementation some more in accordance with the documentation, by
being stricter about handling invalid paths, and making sure to really assign
all of the input _sInPath to the output _rsLocalName in case of an invalid
path.
* Only &...;-decode the names of set elements in ['...'] and ["..."], not
anything else.
Change-Id: If01f4b34af42b0a594994b732d54f26695329286
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...documenting how the implementation is in discordance with the documentation
for some corner cases and how things got recently broken with
5edefc801f "use more string_view in unotools", in
preparation for an upcoming improvement of that function's implementation
Change-Id: Ia47243c64b724009c5ed5eecb9d890820287e9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140492
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...similar to 93e234c45c "Fix a misuse of two-
argument std string_view rfind". This one got introduce in
15d8762dd0 "use more string_view in cui". (And if
it wasn't for other bugs elsewhere, this code could be reached e.g. in Writer
with "Tools - Macros - Organize Macros - Basic...", in "Macro From" select "My
Macros - Standard - Module1" and in "Existing Macros in: Module 1" select
"Main", then "Assign...", and this code would have miscomputed aModule as "Main"
rather than as "Module1".)
Change-Id: Id3fd66e0bd252d79af629abbbf1e38b37679de70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140490
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...introduced in 655b6c2f46
"loplugin:stringviewparam". Unlike its O[U]String lastIndexOf(x, n)
counterpart (which looks for the last x whose end position, exclusive, is <= n),
string_view rfind(x, n) looks for the last x whose start position, inclusive, is
<= n. (So here would have left slash unchanged.) (And the seemingly simpler
jvm_dll.rfind('\\', slash - 1)
would fail when slash is zero, as in that case it would call rfind with a second
argument of npos, i.e., search for the last '\\' in the complete jvm_dll.)
Change-Id: I148a5db860d4b9e9d58a4a8847880a7a7020c5a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140486
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as is used by e.g. Writer's "View - Toolbars - Form Controls", then
Ctrl+click the "Text Box" icon:
After ebd7cc1848 "tdf#150845: sw_uiwriter3: Add
unittest", my 2560x1600 screen Windows laptop kept failing
CppunitTest_sw_uiwriter3 with
> sw/qa/extras/uiwriter/uiwriter3.cxx:962:testTdf150845::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 0
As it turned out, SwDrawBase::GetDefaultCenterPos happened to pick a position
that didn't fall on the single page horizontally centered in the Writer window,
but on the background surrounding it, so in SwFEShell::BeginCreate
(sw/source/core/frmedt/feshview.cxx)
> if ( GetPageNumber( rPos ) )
failed and no control was created (and so the number of shapes expected by the
test wasn't matched).
The logic to adjust aCenter based on aDocSz is there ever since
39ed6bd497 "#104503# put inserted control at a
central position", but that's hard to understand for me because it's hard to
understand for me how SwRootFrame::CheckViewLayout in
sw/source/core/layout/pagechg.cxx computes aNewSize (which is what ends up here
as aDocSz): At least when the Writer window width is larger than necessary to
show the full page, aDocSz.Width() apparently doesn't only measure the page's
width, but also (part of?) the width of the surrounding background on its left,
so the aCenter.setX(...) adjustment could have come up with an X coordinate that
wasn't actually centered on the page as apparently expected by the original
code.
Experimentally, I learned that for the three Writer view modes:
* "Single-page view" corresponds to GetViewLayoutColumns() == 1 and displays the
page horizontally centered in the window.
* "Multiple-page view" corresponds to GetViewLayoutColumns() == 0 and displays
the pages starting flush left in the window.
* "Book view" corresponds to GetViewLayoutColumns() == 2 and displays the two
pages horizontally centered in the window.
And at least when the window width is substantially larger than necessary to
show the one full page of a one-page document (as when showing a default
full-size Writer window on my 2560x1600 screen Windows laptop), the behavior of
inserting a default-positioned Ctrl+click "Text Box" icon is:
* For "Single-page view" it now actually inserts the control, horizontally
centered on the page (instead of not inserting it at all, or inserting it not
horizontally centered).
* For "Multiple-page view" it keeps inserting the control horizontally centered
on the page, as before.
* For "Book view" it keeps not inserting the control, as before, as apparently
before and after it happens to compute positions (albeit different ones) that
fall on the background.
Change-Id: Icf7dd30d4ce81e9d47a3c362f455f721f9e3dd30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140334
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to avoid CppunitTest_vcl_fontfeature
CPPUNIT_TEST_NAME=FontFeatureTest::testGetFontFeaturesOpenType failing with
> vcl/source/font/PhysicalFontFace.cxx:376:48: runtime error: load of value 259, which is not a valid value for type 'NameID'
> #0 in vcl::font::PhysicalFontFace::GetName(vcl::font::NameID, LanguageTag const&) const at vcl/source/font/PhysicalFontFace.cxx:376:48
> #1 in vcl::font::FeatureCollector::collectForTable(unsigned int) at vcl/source/font/FeatureCollector.cxx:124:44
> #2 in vcl::font::FeatureCollector::collect() at vcl/source/font/FeatureCollector.cxx:198:9
> #3 in OutputDevice::GetFontFeatures(std::vector<vcl::font::Feature, std::allocator<vcl::font::Feature>>&) const at vcl/source/outdev/font.cxx:169:23
> #4 in FontFeatureTest::testGetFontFeaturesOpenType() at vcl/qa/cppunit/FontFeatureTest.cxx:143:5
after 06a23b7b4d "vcl: Add
PhysicalFontFace::GetName()".
Per <https://harfbuzz.github.io/harfbuzz-hb-ot-name.html#hb-ot-name-id-t>,
hb_ot_name_id_t is a typedef for unsigned int, and per its referenced
<https://learn.microsoft.com/en-us/typography/opentype/spec/name> OpenType Name
IDs are apparently uint16 values covering the whole value range (e.g., "Name IDs
256 to 32767, inclusive, are reserved for font-specific names"). We could thus
presumably use something like std::uint16_t as the underlying type for NameID,
but lets play it safe (and avoid potential data loss when casting from
hb_ot_name_id_t to NameID) and simply use hb_ot_name_id_t as the underlying
type.
Change-Id: I50768c5ae6174500d959ba63fdbc15fe416f8777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140301
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as seen when CppunitTest_services is run while instdir/share/fonts/ happens
to still be unpopulated (which is otherwise not an issue for that test),
> fcdir.c:268:11: runtime error: null pointer passed as argument 1, which is declared to never be null
> /usr/include/stdlib.h:852:30: note: nonnull attribute specified here
> #0 in FcDirScanConfig at workdir/UnpackedTarball/fontconfig/src/fcdir.c:268:5
> #1 in FcDirCacheScan at workdir/UnpackedTarball/fontconfig/src/fcdir.c:354:10
> #2 in FcDirCacheRead at workdir/UnpackedTarball/fontconfig/src/fcdir.c:462:10
> #3 in FcConfigAddDirList at workdir/UnpackedTarball/fontconfig/src/fccfg.c:537:10
> #4 in FcConfigAppFontAddDir at workdir/UnpackedTarball/fontconfig/src/fccfg.c:2912:10
> #5 in psp::PrintFontManager::addFontconfigDir(rtl::OString const&) at vcl/unx/generic/fontmanager/fontconfig.cxx:748:20
> #6 in psp::PrintFontManager::initialize() at vcl/unx/generic/fontmanager/fontmanager.cxx:711:17
> #7 in GenericUnixSalData::InitPrintFontManager() at vcl/unx/generic/app/gendata.cxx:51:26
> #8 in GenericUnixSalData::GetPrintFontManager() at vcl/inc/unx/gendata.hxx:88:13
> #9 in psp::PrintFontManager::get() at vcl/unx/generic/fontmanager/fontmanager.cxx:108:23
> #10 in GenPspGraphics::GetDevFontListHelper(vcl::font::PhysicalFontCollection*) at vcl/unx/generic/print/genpspgraphics.cxx:264:35
> #11 in FreeTypeTextRenderImpl::GetDevFontList(vcl::font::PhysicalFontCollection*) at vcl/unx/generic/gdi/freetypetextrender.cxx:110:5
> #12 in SvpSalGraphics::GetDevFontList(vcl::font::PhysicalFontCollection*) at vcl/headless/svptext.cxx:51:23
> #13 in OutputDevice::ImplInitFontList() const at vcl/source/outdev/font.cxx:651:17
> #14 in OutputDevice::GetDefaultFont(DefaultFontType, o3tl::strong_int<unsigned short, LanguageTypeTag>, GetDefaultFontFlags, OutputDevice const*) at vcl/source/outdev/font.cxx:532:22
> #15 in SwStdFontConfig::GetDefaultFor(unsigned short, o3tl::strong_int<unsigned short, LanguageTypeTag>) at sw/source/uibase/config/fontcfg.cxx:245:23
> #16 in SwStdFontConfig::SwStdFontConfig() at sw/source/uibase/config/fontcfg.cxx:91:30
> #17 in SwModule::SwModule(SfxObjectFactory*, SfxObjectFactory*, SfxObjectFactory*) at sw/source/uibase/app/swmodule.cxx:150:32
> #18 in std::__detail::_MakeUniq<SwModule>::__single_object std::make_unique<SwModule, SfxObjectFactory*&, SfxObjectFactory*&, SfxObjectFactory*&>(SfxObjectFactory*&, SfxObjectFactory*&, SfxObjectFactory*&) at ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/13.0.0/../../../../include/c++/13.0.0/bits/unique_ptr.h:1076:34
> #19 in SwDLL::SwDLL() at sw/source/uibase/app/swdll.cxx:98:26
> #20 in (anonymous namespace)::SwDLLInstance::SwDLLInstance() at sw/source/uibase/app/swdll.cxx:57:212
> #21 in rtl::Static<(anonymous namespace)::SwDLLInstance, (anonymous namespace)::theSwDLLInstance>::get() at include/rtl/instance.hxx:399:18
> #22 in SwGlobals::ensure() at sw/source/uibase/app/swdll.cxx:70:9
> #23 in SwXAutoTextContainer_get_implementation at sw/source/uibase/uno/unoatxt.cxx:1015:5
Change-Id: Ic0d246e6012b3cd2c9a9deb63c2af7258f31f0d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140214
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and with ScopedFontHDC::fsp gone, there appears to be no reason to keep
ScopedFontHDC::m_aFSP alive for the whole lifetime of the ScopedFontHDC
instance
Change-Id: I1028bc24f49f3bbaf6e23c09aef4459418267154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140100
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> In file included from cppuhelper/source/access_control.cxx:21:
> include\cppuhelper/access_control.hxx(58,5): error: definition of implicit copy assignment operator for 'AccessControl' is deprecated because it has a user-provided copy constructor [-Werror,-Wdeprecated-copy-with-user-provided-copy]
> AccessControl( ::cppu::AccessControl const & ac );
> ^
> include\cppuhelper/access_control.hxx(37,44): note: in implicit copy assignment operator for 'cppu::AccessControl' first required here
> class SAL_WARN_UNUSED CPPUHELPER_DLLPUBLIC AccessControl
> ^
> include\cppuhelper/access_control.hxx(37,23): note: due to 'AccessControl' being dllexported
> class SAL_WARN_UNUSED CPPUHELPER_DLLPUBLIC AccessControl
> ^
> include\cppuhelper/cppuhelperdllapi.h(30,30): note: expanded from macro 'CPPUHELPER_DLLPUBLIC'
> #define CPPUHELPER_DLLPUBLIC SAL_DLLPUBLIC_EXPORT
> ^
> include\sal/types.h(208,47): note: expanded from macro 'SAL_DLLPUBLIC_EXPORT'
> # define SAL_DLLPUBLIC_EXPORT __declspec(dllexport)
Change-Id: I89b534b33c29fdc2d458087e1f3c2f4c958aa86c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression introduced with d2272426cc "Use some
more C++ in sal/osl/w32", found with loplugin:implicitboolconversion.
Change-Id: I5d929dd64bc02559318b8c89cb66bb0f5bba33f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140072
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which started to be an issue when building with recent Clang 16 trunk after
<https://github.com/llvm/llvm-project/commit/3e99b8d947ac024831e59be2b604ac67a24fed94>
"C++/ObjC++: switch to gnu++17 as the default standard" against libc++. (Recent
versions of GCC similarly default to C++17, but libstdc++ by default still
provides bind2nd even for C++17.) Alternatively, we could define
_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS to work around this. But as these appear
to be the only leftover occurrence of bind2nd across all of the code base, and
all but one of them have already been addressed upstream, lets address it for
good with this little patch. (Where the last remaining occurrence not yet
addressed upstream is fixed in the same way as the other upstream fixes, using a
loop rather than e.g. a lambda that would force us to start to pass
CXXFLAGS_CXX11 into ExternalProejct_coinmp.)
Change-Id: Iddcdddd22ea4c6d537b64bf2cf0b887d11da162f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139931
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which started to be an issue when building with recent Clang 16 trunk after
<https://github.com/llvm/llvm-project/commit/3e99b8d947ac024831e59be2b604ac67a24fed94>
"C++/ObjC++: switch to gnu++17 as the default standard" against libc++:
> src/cloop/Main.cpp:31:12: error: no member named 'auto_ptr' in namespace 'std'
> using std::auto_ptr;
> ~~~~~^
(Recent versions of GCC similarly default to C++17, but libstdc++ by default
still provides auto_ptr even for C++17.)
Adding -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR to CXXFLAGS didn't work, though,
as firebird apparently only honors CXXFLAGS during the configure step, but not
in its makefiles. So instead add it directly to CXX. (Adding /all/ the
CXXFLAGS to CXX caused issues at least on Windows, where
<https://ci.libreoffice.org/job/gerrit_windows/135851/> failed with
> Main.cpp
> C:\cygwin\home\tdf\jenkins\workspace\gerrit_windows\workdir\UnpackedTarball\firebird\extern\cloop\src\cloop\Expr.h(25): fatal error C1034: string: no include path set
etc. This probably needs a general clean-up, and the other *FLAGS passed into
the firebird build system might have a similar issue.)
Change-Id: Idf0a5243938fddfb8348cc960074e60dea775650
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139932
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...avoiding to have code in configmgr that knows about the details of the data
stored in the configuration. (See the comments starting at
<https://gerrit.libreoffice.org/c/core/+/139690/9#message-44703a2529c07bf1b0202ed3a232aa661784b159>
"Migrating product name related color schemes between different versions" for
details.)
This reverts the dubious changes of 583ea856f2
"Migrating product name related color schemes between different versions" in
configmgr and offapi. (Also, this moves the computation of sMigratedProductName
in MigrationImpl::copyConfig, desktop/source/migration/migration.cxx, to a saner
location than in the middle of the "check if the shared
registrymodifications.xcu file exists" block where that
583ea856f2 had placed it.)
Change-Id: I7ab3d57db19065c7c818e697300a2abd9e7f72bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139963
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With a randomizing debug-mode libc++, UITest_autofilter2 failed for me with
> FAIL: test_tdf117276_autofilter (tdf117276.tdf117276)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sc/qa/uitest/autofilter2/tdf117276.py", line 78, in test_tdf117276_autofilter
> self.assertFalse(is_row_hidden(calc_doc, 21))
> AssertionError: True is not false
when _LIBCPP_DEBUG_RANDOMIZE_UNSPECIFIED_STABILITY_SEED is e.g. 0.
Change-Id: I3e77731e2f3a2283fcf70293fab39369f316d301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139742
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...(e.g., by setting it in autogen.input). I need that with some of my Clang
builds until the issue discussed in the mail thread
<https://discourse.llvm.org/t/pack-expansion-bug/64910> "Pack expansion bug?" is
sorted out.
(Make sure to even allow passing in an empty
> LIBCPP_DEBUG=
even though it turned out I needed a non-empty
> LIBCPP_DEBUG=-D_LIBCPP_ENABLE_ASSERTIONS=0
in my case.)
Change-Id: I353ab535568ebd5add93485c219fe2a06fde0565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139711
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Stephan Bergmann