...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
They are virtually unused (at least the LibO code base has only a
single use of UNO_REF_QUERY) but confuse static analysis tools that
classify unused function parameters as "tags" (which legalizes the
unusedness of those parameters) if they are of an enum type with
exactly one value defined.
* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
We can't build it here at this point during the build after all. We
use static linking on iOS, and we would need to link with -lgcc3_uno
from bridges which has not been built yet. It seems that any
meaningful unit tests for iOS actually need to be built in a
"subsequent" stage.
Nah, having them behind dbglevel>1 is fine (which already means these
assertions won't normally be compiled even with --enable-debug).
I got mislead as I was building with dbglevel=2 everywhere. But
pondering the point of dbglevel a.k.a. OSL_DEBUG_LEVEL, I think the
right way to see it is: You are not supposed to build all (or large
parts) of LibreOffice with dbglevel=2. If we used OSL_TRACE all over
the place as thoroughly as in some files in sal/rtl, that would lead
to astronomical amounts of tracing output. (We don't use OSL_TRACE
like that, but that is another thing...)
I think the intended use of dbglevel is that you should build with
dbglevel=2 only the small part of code you are currently actively
working on, when you want to see trace output.
Of course, another problem then is that in some modules and/or
libraries it might not be possible to compile just a part of the
sources with dbglevel=2. That should be fixed.
This reverts commit a3bad28550.
