o3tl: ensure that the initializer of enumarray contains enough elements

Currently this silently succeeds. Turns out oox already contains some
too-short initializers, let's guess the missing properties are all
invalid.

One downside of the templated parameter pack approach in the enumarray ctor, as
witnessed in vcl/win/window/salframe.cxx, is that argument types can no longer
be implicitly deduced and thus need to be spelled explicitly now in certain
cases.

There were also three uses of enumarry with V being unsigned short (aka
sal_uInt16) that started to cause narrowing conversion errors now and needed to
be adapted:  In editeng/source/uno/unonrule.cxx the obvious fix was to use the
proper type for V.  In sw/source/core/unocore/unosett.cxx with its odd mix of
saL_Int16 and USHRT_MAX, lets keep things that way for now (probably awaiting
later clean up) and use casts to avoid the implicit narrowing.  And in
sw/source/filter/ww8/wrtw8esh.cxx the ESCHER_Prop_* values, while presumably
conceptionally of type sal_uInt16, are plain #defines (thus of type int), so
rather than changing V to int it looked more consistent to explicitly cast the
ESCHER_Prop_* vlaues to sal_uInt16.

(And in tools/source/fsys/urlobj.cxx the poor loplugin:redundantfcast started to
unhelpfully kick in for (only) the first argument now.)

Change-Id: If06c29e673ec7e565e283c6f447889cf1f777cb7
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135970
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 16 insertions, 1 deletions

diff --git a/include/o3tl/enumarray.hxx b/include/o3tl/enumarray.hxx
index a3c09d56bea0..6abfc9ac53ba 100644
--- a/include/o3tl/enumarray.hxx
+++ b/include/o3tl/enumarray.hxx
@@ -22,6 +22,7 @@
 
 #include <iterator>
 #include <type_traits>
+#include <utility>
 #include <cassert>
 
 namespace o3tl {
@@ -55,6 +56,20 @@ public:
 
     static const size_type max_index = static_cast<size_type>(E::LAST);
 
+    // If this ctor only had the args parameter pack, it would erroneously get picked as a better
+    // choice than the (implicit) copy ctor (taking a const lvalue reference) when a copy is made
+    // from a non-const lvalue enumarray; the easiest way to avoid that is the additional arg
+    // parameter; and to keep things simple that parameter is always passed by const lvalue
+    // reference for now even if there could be cases where passing it by rvalue reference might be
+    // beneficial or even necessary if V is a move-only type:
+    template<typename... T> constexpr enumarray(V const & arg, T && ...args):
+        detail_values{arg, std::forward<T>(args)...}
+    {
+        static_assert(sizeof... (T) == max_index);
+    }
+
+    enumarray() {}
+
     const V& operator[](E index) const
     {
         assert(index>=static_cast<E>(0) && index<=E::LAST);
@@ -78,7 +93,7 @@ public:
 
     V*               data()       { return detail_values; }
 
-//private:
+private:
     V detail_values[max_index + 1];
 };