It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
3af99e4d59d89c343965a928681a30f36b1007d2 "convert equalsAsciiL calls to
startsWith calls" should rather have converted to oprator ==.
Change-Id: Id4a8836c5d6d570e54661c40be7214632e202b21
In commit 363cc397172f2b0a94d9c4dc44fc8d95072795a3
"convert equalsAsciiL calls to startWith calls where possible"
I incorrectly converted equalsAsciiL calls to startsWith calls.
This commit fixes those places to use the == OUString operator.
Change-Id: If76993baf73e3d8fb3bbcf6e8314e59fdc1207b6
Convert code like:
OString aKeyName(RTL_CONSTASCII_STRINGPARAM("NDX"));
to:
OString aKeyName("NDX");
which compiles down to the same code
Change-Id: I1780264cae4484fc78f0586b0750c09f2dce135f
Convert code like:
aStr.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "ActiveConnection" ) )
to
aStr.startsWith( "ActiveConnection" )
which compiles down to the same machine code.
Change-Id: Id4b0c5e0f9afe716a468d3afc70374699848dc33
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
(cherry picked from commit 122e10cfd23b379b97e2d8ec002e7f0562ebd6f7)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/com/sun/star/ucb/makefile.mk
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
ucb/source/ucp/webdav/DAVResourceAccess.cxx
ucb/source/ucp/webdav/DAVResourceAccess.hxx
plus headerize.pl
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: I153e394a194d0fcad29d3e3b27d5b24f7c259fc4
Make css::ucb::XWebDAVCommandEnvironment::getUserRequestHeaders() return
a sequence of css:🫘:StringPair; this avoids all the any overhead,
and is much more simple and intuitive.
(cherry picked from commit 80199136d0d84b51b3d0529fb313b8f20f5cf851)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
ucb/source/ucp/webdav/DAVResourceAccess.cxx
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: I1c5d0a0b225fe86aca6ba6d6c8903985005387c2
It should be derived from css::ucb::XCommandEnvironment
(cherry picked from commit 817e11dccbfe3431f9cc0466051f4d154ce33e5e)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/com/sun/star/ucb/XWebDAVCommandEnvironment.idl
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: Ie44bed44cce09c2423adab33c3790bdcb9be452d
This reverts commit 6c61b20a8d4a6dcac28801cde82a211fb7e30654. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce6708f0e8677dba9cc92e1479a44086 "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d4a6dcac28801cde82a211fb7e30654 again.
I wasn't able to revert without also reverting
be50ad28f5bbdaeff527f646481ce263843c2401 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8fda2a5848e11063028bf44d72f85431
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61b9cabceb9767fad87cd5822b300452
"Fix exception specifications," 2ce6828bbbf6ba181bb2276adeec279e74151ef6 "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce6708f0e8677dba9cc92e1479a44086
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
