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.
* commit 'ooo/DEV300_m101': (185 commits)
chart52: cleanup unused legend entry stuff in preparation of issue #i82802#
masterfix: #i10000# add missing dependency in offapi
sb138: #i115619# fix for MinGW
sb138: #i115619#, #i116038# use osl_setThreadName in binaryurp
sb138: #i115619# osl_setThreadName
gridsort: i116682: update UnoControlDialog to reflect XDialog
gridsort: minor changes to the new API: - renamed XMutableGridDataModel::setRowHeading to updateRowHeading for consistency reasons - renamed XSortableGridDataModel to XSortableGridData - actually, this is not a full-fledged model in itself.
gridsort: grid control related unit tests (first set, more to come)
sb138: #i116038# fresh implementation of binary URP bridge
chart52: #28670# make the legend within charts resizeable - part 2
gridsort: re-did the column resizing - introduced XGridColumn.Flexibility, determining to which degree the column is resized during auto-column-resizing - removed XGridColumn.PreferredWidth - there really is no need for this anymore now - documented the relationship between XGridColumn.Flexibility and XGridColumn.Resizeable - re-implemented TableControl_Impl::impl_ni_updateColumnWidths, with (hopefully) less magic
sb139: #i116530# improve Java URP bridge error notification by utilizing the java.lang.Throwable cause facility
gridsort: document the relationship between soorting the data and notifying XGridDataListeners
gridsort: introduce XGridColumn::DataModelIndex. this allows for column removal/insertion at the GridColumnModel, without the need to touch the GridDataModel
locales34: #i112431# adapt documentation to reality
gridsort: introduce XSortableGridDataModel::removeColumnSort
gridsort: #163172# added UNO API support for sorting grid data. Implementation still unfinished. Things missing in the SortableGridData implementation - add as listener to the delegator, so we're notified of changes - translate and multiplex those changes - do own notifications (XGridDataListener.dataChanged) when the sort order changed - (possibly) update the sort order when the data in the current sort-column changed
gridsort: made the row title a row heading, being an Any instead of a string
gridsort: XMutableGridData: renamed updateRow to updateRowData for consistency; introduced updateRowToolTip as shortcut for multiple updateCellToolTip calls
gridsort: updateCell->updateCellData, setCellToolTip->updateCellToolTip; in both methods, have (Col,Row) params instead of (Row,Col), for consistency reasons
...
Conflicts:
bridges/inc/bridges/remote/bridgeimpl.hxx
bridges/inc/bridges/remote/connection.h
bridges/inc/bridges/remote/context.h
bridges/inc/bridges/remote/helper.hxx
bridges/inc/bridges/remote/mapping.hxx
bridges/inc/bridges/remote/proxy.hxx
bridges/inc/bridges/remote/remote.h
bridges/inc/bridges/remote/remote.hxx
bridges/inc/bridges/remote/stub.hxx
bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx
bridges/source/remote/context/context.cxx
bridges/source/remote/static/helper.cxx
bridges/source/remote/static/mapping.cxx
bridges/source/remote/static/proxy.cxx
bridges/source/remote/static/remote.cxx
bridges/source/remote/static/remote_types.cxx
bridges/source/remote/static/remote_types.hxx
bridges/source/remote/static/stub.cxx
bridges/source/remote/urp/urp_bridgeimpl.cxx
bridges/source/remote/urp/urp_bridgeimpl.hxx
bridges/source/remote/urp/urp_cache.h
bridges/source/remote/urp/urp_cache.hxx
bridges/source/remote/urp/urp_dispatch.cxx
bridges/source/remote/urp/urp_dispatch.hxx
bridges/source/remote/urp/urp_environment.cxx
bridges/source/remote/urp/urp_job.cxx
bridges/source/remote/urp/urp_job.hxx
bridges/source/remote/urp/urp_log.cxx
bridges/source/remote/urp/urp_log.hxx
bridges/source/remote/urp/urp_marshal.cxx
bridges/source/remote/urp/urp_marshal.hxx
bridges/source/remote/urp/urp_marshal_decl.hxx
bridges/source/remote/urp/urp_property.hxx
bridges/source/remote/urp/urp_propertyobject.cxx
bridges/source/remote/urp/urp_propertyobject.hxx
bridges/source/remote/urp/urp_reader.cxx
bridges/source/remote/urp/urp_reader.hxx
bridges/source/remote/urp/urp_replycontainer.hxx
bridges/source/remote/urp/urp_threadid.cxx
bridges/source/remote/urp/urp_threadid.hxx
bridges/source/remote/urp/urp_unmarshal.cxx
bridges/source/remote/urp/urp_unmarshal.hxx
bridges/source/remote/urp/urp_writer.cxx
bridges/source/remote/urp/urp_writer.hxx
cppu/source/threadpool/threadpool.cxx
cppu/util/target.pmk
cppuhelper/qa/propertysetmixin/comp_propertysetmixin.cxx
cppuhelper/source/interfacecontainer.cxx
cpputools/source/regcomplazy/regcomplazy.cxx
jurt/prj/d.lst
jvmfwk/source/elements.cxx
offapi/com/sun/star/awt/grid/GridDataEvent.idl
offapi/com/sun/star/awt/grid/XGridColumn.idl
offapi/com/sun/star/awt/tab/makefile.mk
offapi/com/sun/star/chart2/ExplicitIncrementData.idl
offapi/com/sun/star/chart2/XPlotter.idl
offapi/com/sun/star/chart2/XUndoHelper.idl
offapi/com/sun/star/document/MediaDescriptor.idl
offapi/com/sun/star/document/makefile.mk
offapi/com/sun/star/linguistic2/XLanguageGuessing.idl
offapi/com/sun/star/script/ModuleInfo.idl
offapi/com/sun/star/script/ModuleType.idl
offapi/com/sun/star/text/TextMarkupType.idl
offapi/com/sun/star/util/XTextSearch.idl
offapi/com/sun/star/xml/sax/XFastAttributeList.idl
pyuno/source/loader/makefile.mk
remotebridges/source/bridge/bridge_connection.cxx
remotebridges/source/bridge/bridge_connection.hxx
remotebridges/source/bridge/bridge_provider.cxx
remotebridges/source/bridge/remote_bridge.cxx
remotebridges/source/bridge/remote_bridge.hxx
remotebridges/source/dynamicloader/dynamicloader.cxx
remotebridges/source/factory/bridgefactory.cxx
remotebridges/source/factory/bridgeimpl.cxx
remotebridges/source/factory/bridgeimpl.hxx
remotebridges/source/factory/makefile.mk
sal/cppunittester/cppunittester.cxx
sal/inc/osl/diagnose.h
sal/osl/os2/system.h
sal/osl/unx/diagnose.c
sal/osl/unx/file_misc.cxx
sal/osl/unx/process_impl.cxx
sal/osl/w32/diagnose.c
sal/osl/w32/process.cxx
sal/prj/build.lst
sal/qa/rtl/math/makefile.mk
sal/qa/rtl/math/rtl_math.cxx
sal/qa/rtl/math/rtl_old_testint64.cxx
sal/qa/rtl/math/test_rtl_math.cxx
sal/systools/win32/kill/kill.cxx
sal/textenc/tencinfo.c
sal/util/sal.map
stoc/source/inspect/introspection.cxx
stoc/source/security/file_policy.cxx
stoc/source/simpleregistry/simpleregistry.cxx
Those assertions were dependent on OSL_DEBUG_LEVEL > 1 (i.e. only existent with "dmake=1"), and then always
fired. Which fulfills the definition of "useless", /me thinks.
Re-introduce the possibility to define CPPU_LEAK_STATIC_DATA. This
time use it to bypass just the assertions that check that the type
description counts really are zero at the end of the
TypeDescriptor_Init_Impl destructor.
Add more informative debugging printout of which counts are non-zero.
Define CPPU_LEAK_STATIC_DATA for x64 Windows for now. But we do get
the same assertions also on x86 Windows if cppu is built with
OSL_DEBUG_LEVEL>1.
We do print out a message if struct size verifications fail. That is
enough. No point in printing out the same
> sizeof(AlignSize_Impl) = 16
> sizeof(M) = 8
> sizeof(N) = 12
etc messages every time a cppu-using program is run and cppu has been
built for debugging.
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
