as in fd2e467ba3 for netproduce.cxx
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx: In member function ‘rtl::OString RustProducer::resolveTypedef(std::u16string_view) const’:
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx:1421:43: error: ‘Typedef’ is not a member of ‘codemaker::UnoType::Sort’
1421 | if (sort == codemaker::UnoType::Sort::Typedef)
| ^~~~~~~
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx: In member function ‘bool RustProducer::isUnoInterface(std::u16string_view) const’:
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx:1713:46: error: ‘Interface’ is not a member of ‘codemaker::UnoType::Sort’
1713 | return sort == codemaker::UnoType::Sort::Interface;
| ^~~~~~~~~
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx: In member function ‘bool RustProducer::isUnoStruct(std::u16string_view) const’:
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx:1721:46: error: ‘PlainStruct’ is not a member of ‘codemaker::UnoType::Sort’
1721 | return sort == codemaker::UnoType::Sort::PlainStruct;
| ^~~~~~~~~~~
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx: In member function ‘bool RustProducer::isUnoEnum(std::u16string_view) const’:
/home/rene/LibreOffice/git/master/codemaker/source/rustmaker/rustproduce.cxx:1729:46: error: ‘Enum’ is not a member of ‘codemaker::UnoType::Sort’
1729 | return sort == codemaker::UnoType::Sort::Enum;
| ^~~~
Change-Id: I36c97fcfec14fb075d67aa4e1550dadba7499aa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193621
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Replace generic void* parameters with proper types (strings, primitives, structs) for better type safety and more idiomatic Rust code.
Change-Id: Iced1c2de96564be7ec599f14bf1a685eaede2768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191477
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Address the following clang plugin error seen in an
--enable-rust-uno build:
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:1016:41: error: rather than copy, pass with a view using subView() [loplugin:stringview]
1016 | && (unoType.copy(unoType.lastIndexOf('.') + 1).startsWith("X")));
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Icec8b529abf67ca13243da21136d5f296f53b7d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190854
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch some params from const std::string& to std::string_view
and drop the then unnecessery calls to OString::getStr in
callers.
This fixes the following clang plugin errors seen in an
--enable-rust-uno build:
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:1070:88: error: unnecessary call to 'getStr' when passing to string constructor [loplugin:unnecessarygetstr]
1070 | generateStructSourceBasicFunctions(file, functionPrefix, handleTypeName, className.getStr());
| ~~~~~~~~~~^~~~~~~~
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:1073:85: error: unnecessary call to 'getStr' when passing to string constructor [loplugin:unnecessarygetstr]
1073 | generateStructSourceBaseMembers(file, functionPrefix, handleTypeName, className.getStr(),
| ~~~~~~~~~~^~~~~~~~
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:1077:87: error: unnecessary call to 'getStr' when passing to string constructor [loplugin:unnecessarygetstr]
1077 | generateStructSourceDirectMembers(file, functionPrefix, handleTypeName, className.getStr(),
| ~~~~~~~~~~^~~~~~~~
Change-Id: Ia0ad68dd2dfed3a9b807c284e474ae0f2e42b2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190853
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Fix clang plugin errors like the following seen in an
--enable-rust-uno build:
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:207:77: error: replace function parameter of type 'const OString &' with 'std::string_view' [loplugin:stringviewparam]
207 | void CppProducer::generateCBridgeConstructors(CppFile& file, const OString& className,
| ~~~~~~~~~~~~~~~^~~~~~~~~
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.hxx:177:75: note: previous declaration is here [loplugin:stringviewparam]
177 | static void generateCBridgeConstructors(CppFile& file, const OString& className,
| ~~~~~~~~~~~~~~~^~~~~~~~~
Change-Id: I5d5fa38d735a63438395848d6038f9d0e8e40401
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190852
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Fix clang plugin errors like the following seen in an
--enable-rust-uno build:
In file included from /home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:10:
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.hxx:177:10: error: this member function can be declared static [loplugin:staticmethods]
177 | void generateCBridgeConstructors(CppFile& file, const OString& className,
| ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
178 | const OString& functionPrefix, const OString& handleTypeName);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I7d2ae9ba71da8a6db73101e177610e9ec0df7616
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190850
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This fixes clang plugin errors like the following
seen in an --enable-rust-uno build:
.../libreoffice/codemaker/source/rustmaker/rustproduce.cxx:1063:16: error: use a _ostr user-defined string literal instead of constructing an instance of 'OString' from an ordinary string literal [loplugin:ostr]
1063 | return "u8";
| ^~~~
Change-Id: I5891641b80b46e19f1ceb401e48b6a8fb0286e58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190848
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The rustmaker provides comprehensive support for converting UNO type definitions into idiomatic Rust code with proper memory safety and type system integration.
Also adds the RustFile, RustOptions, and RustProducer classes to handle
Rust code generation, file management, and command line option parsing
for various UNO type kinds such as enums, structs, and interfaces.
Change-Id: Iaf87af13352c55e81c1745ef7a8f591c3e61e0a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188088
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
This commit introduces the 'pythonmaker' executable, a new tool in the
codemaker module.
pythonmaker generates Python type stub files (.pyi) from UNO IDL type
libraries (.rdb files). This enables static type checking and modern
IDE features like auto-completion for developers writing Python scripts for LibreOffice.
This commit includes the complete, feature-complete tool capable of handling all major IDL entity types (enums, constants, typedefs,
structs, exceptions, interfaces, services, and singletons).
Change-Id: I52f783aa982e1de04a207a9a884aee207f99d193
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185498
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...to avoid
> error CS0266: Cannot implicitly convert type 'double' to 'float'. An explicit conversion exists (are you missing a cast?)
(as would e.g. happen if offapi/org/libreoffice/embindtest/Constants.idl were
included in regular builds)
Change-Id: I6a4d8b151755edd3a8b03d73e2bb546cf1d19e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174200
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This patch includes all marshalling and proxy handling code on the
.NET side as well as the native side needed for a fully functional
UNO bridge.
It also includes some changes and corrections to net_basetypes and
netmaker needed for the bridge to work properly.
It also includes the FirstUnoContact example in C# as demonstration.
Change-Id: I406932938a4415d24408fb41ddfa7d8eeb5d1f94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170916
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This commit makes a few misc. fixes to netmaker and net_basetypes
- Renamed css.uno.Exception to css.uno.UnoException to avoid name
conflicts with System.Exception
- Added a new css.uno.Any constructor and setValue function that
deduces the type of the any from given object at runtime
- Changed the AnyTests unit tests to match changes made to css.uno.Any
- Removed the in keyword from UNO 'in' parameters. Was a premature
optimisation that might have a negative effect for certain types.
- Generated struct and exception field members were not marked public
earlier by accident, fixed.
- Generted struct and exception constructors had parameters in order
opposite to expected, fixed.
- Generated services tried to instantiate the interface, not the
service earlier, fixed.
Change-Id: Ia63f9db469db13a5d01617617095b8f568b39c72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171706
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As Mike noticed, the pb is more general than just Base forms.
So here's the general fix suggested by Mike (thank you for the help!)
Change-Id: Ic57039c9c37f26d2ea2d0e0bda89f277ba7044cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171337
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Add new overloads to OUString methods that have a
"OUString* rest" style parameter.
Instead return a view, which does not require allocation.
To avoid overload ambiguity, split the methods into
different variants that do not use default parameters.
Change-Id: I1aa366115750f1f7ea4fe665804195f59f7c4b69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167632
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This commit adds the netmaker executable to the codemaker/ module, to
generate C# code from UNOIDL specifications.
Also adds some Makefiles in the net_ure/ directory to generate code for
udkapi and offapi, to build the net_uretypes and net_oootypes assemblies.
Change-Id: Ifb61fe6a0f8f594eaa6ff95b025ba57f247b0d4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168710
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Because I want to make more symbols private, but that runs into a
problem with the special symbol "typeinfo for Foo" which is required for
dynamic_cast.
For clang, we can use SAL_DLLPUBLIC_RTTI to make just that magic
"typeinfo for Foo" symbol visible.
But for gcc, we are left with no option but to make the whole class
visible via <MODULE>_DLLPUBLIC.
(I have a feature request logged against gcc to support something like
that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958)
But I also don't want to use <MODULE>_DLLPUBLIC, since that blocks
progress of reducing symbol visibility for platforms other than gcc.
So map SAL_DLLPUBLIC_RTTI to visiblity:default for gcc, which means that
only gcc suffers the negative affects of not having that annotation.
However, that runs into the problem that gcc does not like
visibility:default in a couple of places, so I have to introduce some
extra preprocessor stuff.
Change-Id: Ib4fc5c1d2a1f8cf87d5159a4b5684137ec061605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which had been added all the way back in 2002 with
6cd0bbd8ce "adding new file to HEAD" to constants
group css.drawing.CaptionEscapeDirection, which has meanwhile been published, so
no chance of cleaning that up.
But cppumaker already has a mechanism to work around problematic UNOIDL
identifiers, but which was only used for "new-style" entities when they got
introduced, mainly to avoid compatibility issues when retroactively changing the
code generated for existing entities.
But for C++ keywords, the generated code was always broken, so no harm in fixing
it, so introduce an additional IdentifierTranslateMode::KeywordsOnly and use
that at least for constants, to address the immediate issue.
(And with that, a hack can be removed from gb_UnoApiEmbindTarget__add_embind.)
Change-Id: I5cf62fd8b3b298dff2ec28452fb97b424a4ba473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
For one, no need to wrap in #ifdef EMSCRIPTEN code that is only ever fed into
emcc anyway. For another, better use fully qualified names throughout generated
code, to avoid unexpected collisions.
Change-Id: I939728c7e0601e5fb3f3634bbd62f35042d91105
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162266
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and
cid#1546284 Using invalid iterator
cid#1546275 Using invalid iterator
cid#1546049 Using invalid iterator
cid#1545929 Using invalid iterator
cid#1545870 Using invalid iterator
cid#1545668 Using invalid iterator
cid#1545420 Using invalid iterator
Change-Id: I3ad3000631b4be5917b9c5f49f21b8cc003a309c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159056
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and :
cid#1545537 Using invalid iterator
cid#1545508 Using invalid iterator
cid#1545494 Using invalid iterator
cid#1545478 Using invalid iterator
cid#1545427 Using invalid iterator
cid#1545420 Using invalid iterator
cid#1545400 Using invalid iterator
cid#1545300 Using invalid iterator
cid#1545258 Using invalid iterator
cid#1545257 Using invalid iterator
cid#1545200 Using invalid iterator
cid#1545183 Using invalid iterator
Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Rene Engelhard