The below is done, meanwhile. Two items to note:
* Consequently, no longer necessary #includes have been removed from
cppumaker-generated files, which may cause 3rd-party code (or any LO
code I didn't manage to compile myself---but I tried hard) to no longer
compile (to fix, add the missing #includes to the client code).
* Only after doing the automatic conversion did I discover now that
dynamic exception specifications on deallocation functions should have
been replaced with 'noexcept(false)' instead of just dropping them.
However, I think there were no such in our code base to begin with.
On 01/18/2017 02:03 PM, Stephan Bergmann wrote:
For better or worse, dynamic exception specifications (the "throw (ex1,
ex2, ex3)" part of function declarations) were deprecated in C++11 and
will be removed from the language entirely in C++17. (The new
alternative being 'noexcept'.)
Consequently, (current trunk builds towards) GCC 7 issues a -Wdeprecated
warning for each dynamic exception specification it encounters. Which
for us means that we'll need to come up with a plan for the exception
specifications across the LO code base, short of bluntly disabling all
kind of -Wdeprecated for GCC 7---which is hardly what we want to do
going forward.
There are four cases to consider:
A URE interface include files.
B Generated UNO API include files.
C "Plain" LO internal code.
D "External" code where LIBO_INTERNAL_ONLY is not defined: SDK
examples, extension code.
Instead of coming up with new macros (after we've successfully removed
SAL_THROW in the past) to hide dynamic exception specifications behind,
my proposal is to remove them completely from all of the code (on
current master towards LO 5.4).
For 3rd-party code interfacing with A+B, that change should be backwards
compatible.
For anything but dtors, removing the dynamic exception specification
implicitly makes the function nothrow(false). For dtors, the dynamic
exception specification would be replaced with an explicit
nothrow(false). An empty 'throw ()' will be reclassified as not a
dynamic exception specification in C++17 (and GCC 7 doesn't emit
-Wdeprecated for it); occurrences of that will remain unchanged.
I'd do the change in the following steps:
1 Remove dynamic exception specifications from A+C (with the help of a
rewriting Clang plugin).
2 Build the D code to demonstrate that changing A is indeed backwards
compatible.
3 Remove dynamic exception specifications from B (by modifying cppumaker).
4 Build the D code to demonstrate that changing B is indeed backwards
compatible.
5 Remove dynamic exception specifications from D.
Now, knowing what kinds of exceptions a function is intended to throw is
useful information, arguably part of the function's interface even.
Removing dynamic exception specifications would thus remove useful
documentation in many cases.
Therefore, I'd introduce a preliminary step
0 With the help of a Clang plugin, find functions with dynamic
exception specifications for which Doxygen-style documentation is
missing, and add such @throws clauses.
I'd not do that step 0 for B (those generated files are not really
human-friendly anyway, and the information is readily available in the
corresponding UNOIDL files), and also generally restrict it to
non-overriding functions.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
