There is really no need to see tons of
component context fails to supply service <something long> of type <something else long>:
and
component context fails to supply service <something long> of type <something else long>
in the binary ;-) - let's split the strings to parts that the linker can
share easily.
Change-Id: I07f149a587c05985045028c3b6530c6efd081ff5
Missing in c2c530da69152ff9192b9726aa95961803ce9b29 "Introduce static
inline cppu::acquire(), and make use of that."
Change-Id: I4a856eeaff1fce3f429c62c1897fe3898371d1ec
Most of the constructors are supposed to be only a call of
new TheInstance(arguments)
or an equivalent; so let's just change the constructor caller accordingly, to
accept unacquired new instance.
If there are exceptions that need to do more heavy lifting, they do not have
to use the constructor feature, or there can be a wrapper for the real
implementation, doing the additional work in their (C++) constructor.
Change-Id: I035c378778aeda60d15af4e56ca3761c586d5ded
...so that exceptions like std::bad_alloc need not be treated in C++
implementations of UNO interfaces to not cause std::unexpected. Of course, this
requires implementations to be adapted and actually mention std::exception in
their exception specifications.
Change-Id: Ie7f91e7ca47d8a81e3d0ba817e65d83c7823af75
...the list has been fixed now by copying its elements into an ENTRIES file and
running "unoidl-write udkapi/ @ENTITIES TEMP && unoidl-read TEMP >/dev/null" and
adding any reported unknown entities until it succeeds.
However, the updated list lead to deadlock when css.reflection.ParamInfo UnoType
resolves css.reflection.XIdlClass UnoType resolves css.reflection.XIdlMethod
UnoType resolves css.reflection.ParamInfo UnoType, so broke the circle by no
longer resolving the interface methods' return and parameter types in
InterfaceType::dumpMethodsCppuDecl (which is why those type infos are only
generated on demand anyway; looks like this had been a careless thinko in the
generation of comprehensive type info that had remained unnoticed all the time).
Change-Id: I50ef2fde16242298e055c6fa5971e70fad1a2b68
This reverts commit c4113906d7f15f8aa0eb385a4caf474b3505ede1, which is not
necessary after all with recent "Hook SourceProvider into unoidl::loadProvider."
...used for now to transport @deprecated information.
Also, improve Idx-String (formerly Idx-Name, but also used for UTF-8 annotations
now) format, using the 0x80000000 for the indirection rather than the base case.
(And the README erroneously used "Offset of" Idx-String all over the place.)
Change-Id: I7003b1558ab536a11a9af308f9b16a7ef8840792
Make cppumaker work on top of unoidl/ instead of registry/, as a first step to
change all the various codemakers.
* API CHANGE: cppumaker no longer supports the -B switch, as that is meaningless
with the new format. When reading from an old-format .rdb file, /UCR is
hard-coded as the prefix now.
* TODO: The new format does not yet support deprecation annotations, so the
generated .hdl/.hpp files lack any SAL_DEPRECATED_INTERNALs for now.
* codemaker/typemanager.hxx is extended with access to unoidl/ functionality, so
the various codemakers can use registry/ and unoidl/ in parallel for now.
The access to registry/ functionality will be removed. (Added small throwaway
helper functions u2b/b2u to easily map between OString and OUString at the
remaining seams for now.)
* Includes a selective revert of ba044b1e9613ed30906a9a540b7da8392923e4e3
"remove needless forward rtl::OUString declarations" in those parts of
codemaker, unodevtools, unoidl that were covered by this local
work-in-progress patch; I would otherwise have hard a hard time re-applying
it.
* The generated .hdl/.hpp files are mostly unchanged, except for a few minor
things:
** Any SAL_DEPRECATED_INTERNALs are missing (see above).
** In comprehensive getCppuType definitions, some members were erroneously
classified as TypeCalss_UNKNOWN.
** In comprehensive getCppuType definitions, some unnecessary calls like
::cppu::UnoType< ::sal_Int32 >::get();
can be removed.
** For typedef sequence<X>, the .hdl file need not include X.hdl, but only needs
to forward-declare it.
** Unnecessary includes for optional bases of interfaces can be removed.
** Some numbering of local variable names (sMethodName1, ...) has changed.
Change-Id: Icad98f248ac15177337f1b4ab709a755a8af6238
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
...so include the latter in isBootstrapType too, see
dee53a32a9feba2021782db5762b5a9a034efae4 "Temporary hack around
cppu_detail_getCppuType variants violating ODR."
Change-Id: I613cf3d8699eccb149e0e1d31f4398a426ce0966
...that had once been workarounds for compilers that did not yet support the
C++98 scoping rules for declarations in for-init-statements.
Change-Id: I51dc42982b30bf3adea6de1a10a91c0b4b4acfbe
...as had been done in 0295bd6b3f21dd648af6145ca23d90467f3cec73 "Remove
exception spec from idl-generated c++ headers."
Change-Id: I1b900a91be6db6cb4d7b60759e844117aa6b027d
Exception specifications are useless for production code, but make
for useful assertions in dbgutil builds (on platforms where they
are enforced at runtime).
Because we do not have API tests that exhaustively trigger all
documented error conditions, much less the undocumented or wrongly
handled error conditions that would cause the implementation to violate
its API specification, there is likely some benefit in having these
runtime-checked specifications in debug builds, in the hope that our
various tests which may incidentally call various API methods, or
general soffice usage, uncovers these bugs.
Also, there may be some benefit to making API implementers more
aware of the exception specifications, to quote Stephan's mail:
To be able to programmatically react to an exception raised by a UNO
method (which is the raison d'être of non-runtime UNO exceptions), the
specification of that method must document the method's behavior with
respect to raising that exception, and any implementation of the method
must adhere to that specification. However, with that part of a UNO
method's interface moved out of sight of a programmer writing a C++
implementation of that method, I fear that adherence to specification
will degrade in practice. And that negatively affects an area where we
do not shine anyway: reaction to errors.
This partially reverts commits:
0295bd6b3f21dd648af6145ca23d90467f3cec73
155cd09b5eebe0c1eab0610a7f1f04f09de4b217
Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440
The general agreement in the project is that c++ exception
specs are pointless and add bloat in production code.
See also this rant for more background:
http://drdobbs.com/cpp/184401544
This removes the code that generates the exception specs on the
generated c++ headers, and fixes up the few places that broke
subsequently because of widening exception specs, which in turn
was due to the rather unfortunate decision to not have a virtual
dtor in XInterface.
Change-Id: I60db26e1cc4d4fe6eeef5975e39497841e92588a
...as there are typically no direct calls to it anyway. What is apparently
needed is to decorate the cppumaker-generated headers instead:
* cppumaker obtains deprecation-information from the documentation strings in
.rdb files. As these are normally generated by idlc without documentation
included (no -C), idlc got changed to nevertheless contain documentation
consisting of just "@deprecated" in this case, to allow to easily tunnel this
information to cppumaker always.
* The mechanism of parsing for "@deprecated" in documentation strings is
somewhat crude, of course.
* For now, cppumaker only decorates C++ functions that correspond to UNOIDL
interface attributes and methods. More should be possible (but, e.g., being
able to decorate a complete C++ class corresponding to a deprecated UNOIDL
interface type depends on whether all platforms would accept
SAL_DEPRECATED_INTERNAL at the same position in a C++ class declaration.
* This could also be extended to other languages than C++/cppumaker.
* Always using SAL_DEPRECATED_INERNAL instead of SAL_DEPRECATED for decoration
is to keep things simple and our codebase working. Improvements are possible
here, too, of course.
Change-Id: Ia2917892f780d477652e4cd9f286588a6898c3f5
Not needed now when we always generate comprehensive UDKAPI headers in
the configuration where I thought the reverted change helped (it
actually didn't).
This reverts commit 73c3907bce33c07ef78c0bb9ff1e0df8b9fbb323.
Change-Id: Iabbfec9b8e9d6963b31daa52dc574bed01d9eb4c
This is in a Mac build tree using the 10.7 SDK and latest Xcode Clang.
This codemaker-generated type stuff seems awfully fragile. Should we
just bite the bullet and do the "comprehensive" thing for all UDKAPI
types all the time on all platforms? Is that a sane question to ask?
Change-Id: I9d17e76a83ff71898409179acb445832436f7bbd
Needed for some unknown reason in a 64-bit Mac LO. Doesn't do any harm
to have it included everywhere.
Change-Id: I62ae599692bb922678caabe78b7e1c0588573bb2
This is such a fatal error that there is probably no point in trying to handle
it, so allow to simplify client code by removing the requirement to check for a
null return value.
Simplified some client code accordingly (modules configmgr and ure, and the code
generated by cppumaker and javamaker).
Change-Id: I51c0b270ec73409374f7439a47ee061407a46e31
...it is base of XInterfaceTypeDescription2 (included in isBootstrapType), which
ultimately caused uno-skeletonmaker to crash.
Change-Id: I17421f58efd9edd4112532a3221125865cc5560e
