...and std::filesystem::path::generic_string, which at least GCC 17 trunk
libstdc++ now flags for C++26 (--with-latest-c++) as
> In file included from engine/codemaker/source/netmaker/netproduce.cxx:19:
> engine/codemaker/source/netmaker/csharpfile.hxx:28:53: error: 'string' is deprecated: use 'display_string' or 'native_encoded_string' instead [-Werror,-Wdeprecated-declarations]
> 28 | std::string getPath() const { return m_filePath.string(); }
> | ^
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/bits/fs_path.h:465:5: note: 'string' has been explicitly marked deprecated here
> 465 | _GLIBCXX26_DEPRECATED_SUGGEST("display_string' or 'native_encoded_string")
> | ^
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/x86_64-pc-linux-gnu/bits/c++config.h:160:45: note: expanded from macro '_GLIBCXX26_DEPRECATED_SUGGEST'
> 160 | # define _GLIBCXX26_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
> | ^
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/x86_64-pc-linux-gnu/bits/c++config.h:112:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
> 112 | __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
> | ^
since
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=341ad729c2c93b9f01854913b0404e4fc8958512>
"libstdc++: Add (generic_)display_string and (generic_)native_encoded_string to
filesystem::path".
Occurrences that are obviously meant for display purposes are #if-conditionally
replaced with the new display_string, while all other occurrences are left using
the (non-deprecated) [generic_]string<char> template instantiation, matching the
original code. (Where, for C++26, the latter could also be replaced with the
new [generic_]native_encoded_string, aka [generic_]system_encoded_string; see
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2319r5.html>
"Prevent path presentation problems" and
<https://cplusplus.github.io/LWG/issue4512> "The system_encoded_string() and
generic_system_encoded_string() member functions of std::filesystem::path are
misnamed" for details.)
Signed-off-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Change-Id: I7c79c8522608550bb1e0f4cb8e4824480952446b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3987
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit f320d95d89ecc9bea81182795969f83b05ec903c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206226
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Language Code Generators for UNOIDL Entities
Generators for language-binding--specific representations of UNOIDL entities:
cppumakergenerates header (.hdland.hpp) files for the C++ UNO language bindingjavamakergenerates class files for the JVM language bindingnetmakergenerates C# code files for the .NET language bindingclimaker(the old codemaker for .NET Framework) is in modulecli_urepythonmakergenerates Python stub (pyi) files for the Python UNO language binding
Some of the code is re-used by the skeletonmakers in module unodevtools.
Note the different terminology used by cppumaker vs. gbuild for the three variants that can be generated by cppumaker for some of the inline functions:
cppumaker switch: -L; cpputype.cxx: light; gbuild: normal;
cppumaker switch: none; cpputype.cxx: normal; gbuild: bootstrap;
cppumaker switch: -C; cpputype.cxx: comprehensive; gbuild: comprehensive;
which can be a source of confusion.