Closes: #165

Merge branch 'avoid-vc-cpu-detection' into 'master'

ref:core/dune-common Vc detects CPU flags based on the name of the CPU. This
can be a problem in virtualization environment, when the name of the CPU is
visible, but not all features are enabled in the guest.

Also, enabling all detected features in the the compiler makes it difficult to
impossible for the user to force his own feature flags, e.g. to cross-build
generic executables on hosts with many features to be run later on hosts with
fewer features.

Closes: [docker/ci#9]

WIP:

-   [x] properly test, in particular in the light of [docker/ci!46] being
    applied to the ci images
-   [x] ansgar [proposed] getting rid of all the Vc_COMPILE_FLAGS, too. Try
    that: [!679] (redifined [!679] as an add-on to this one, so it does not
    stop me from merging this one)
-   [x] changelog entry (deferred to [#163])

See merge request [!677]

  [docker/ci#9]: gitlab.dune-project.org/docker/ci/issues/9
  [docker/ci!46]: gitlab.dune-project.org/docker/ci/merge_requests/46
  [proposed]: docker/ci#9 (comment 56350)
  [!679]: gitlab.dune-project.org/NoneNone/merge_requests/679
  [#163]: gitlab.dune-project.org/NoneNone/issues/163
  [!677]: gitlab.dune-project.org/core/dune-common/merge_requests/677


Closes docker/ci#9

Merge branch 'fix-return-type-of-sequential-allreduce' into 'master'

See merge request [!678]

  [!678]: Nonecore/dune-common/merge_requests/678

Vc detects CPU flags based on the name of the CPU.  This can be a problem in
virtualization environment, when the name of the CPU is visible, but not all
features are enabled in the guest.

Also, enabling all detected features in the the compiler makes it difficult to
impossible for the user to force his own feature flags, e.g. to cross-build
generic executables on hosts with many features to be run later on hosts with
fewer features.

Closes: docker/ci#9

Merge branch 'fix-macro-not-expecting-semicolon' into 'master'

ref:core/dune-common This avoids certain compiler warnings about unneccessary
;. It plays nicer with automatic editor indentation compared to the the
alternative of dropping the ; from every invocation of the macro (see [!673]
for that).

Alternative to: [!673]

WIP:

-   [x] Waiting for feedback from @gruenich

See merge request [!675]

  [!673]: gitlab.dune-project.org/NoneNone/merge_requests/673
  [!675]: gitlab.dune-project.org/core/dune-common/merge_requests/675

Merge branch 'fix/move-on-local-object' into 'master'

See merge request [!674]

  [!674]: Nonecore/dune-common/merge_requests/674

Merge branch 'feature/default-constructible-variant' into 'master'

ref:core/dune-common The behaviour of the default constructor
`std::variant<T0, ...>` is as follows:

-   \(a) If T0 is default constructible, then the variant will hold a
    value-initialized T0 and the index is 0.
-   \(b) If T0 is not default constructible, then the default constructor does npt
    participate in overload resolution.

In contrast to this until now the following is implemented

-   \(c) The default constructor of Std::variant does alway exist and will
    initialize it with a special invalid state (which is BTW not copyable).

Having (c) instead of (a) especially prevented copying default constructed
`Std::variant<Std::monostate, ...>` objects.

This patch at least ensures (a) but keeps (c) if T0 is not default
constructible. The reason for the latter is, that (b) is much harder to fix
and unlikely to lead to problems.

See merge request [!676]

  [!676]: gitlab.dune-project.org/core/dune-common/merge_requests/676

The behaviour of the default constructor `std::variant<T0, ...>` is as follows:

* (a) If `T0` is default constructible, then the `variant` will hold
  a value-initialized `T0` and the index is 0.
* (b) If `T0` is not default constructible, then the default constructor
  does npt participate in overload resolution.

In contrast to this until now the following is implemented

* (c) The default constructor of `Std::variant` does alway exist
  and will initialize it with a special invalid state (which
  is BTW not copyable).

Having (c) instead of (a) especially prevented copying default
constructed `Std::variant<Std::monostate, ...>` objects.

This patch at least ensures (a) but keeps (c) if `T0` is not
default constructible. The reason for the latter is, that (b)
is much harder to fix and unlikely to lead to problems.

This avoids certain compiler warnings about unneccessary `;`.  It plays nicer
with automatic editor indentation compared to the the alternative of dropping
the `;` from every invocation of the macro (see !673 for that).

Merge branch 'fix/pis_iter_op_copy' into 'master'

See merge request [!667]

  [!667]: !667

Merge branch 'feature/document-overload-issue' into 'master'

ref:core/dune-common Document a potential issue and a workaround with
Dune::overload and Dune::orderedOverload for captureless lambdas on gcc 5 and
6. Additionally this adds a test case for the problem making use of the
proposed workaound.

See merge request [!668]

  [!668]: gitlab.dune-project.org/core/dune-common/merge_requests/668

Document a potential issue and a workaround with `Dune::overload` and
`Dune::orderedOverload` for captureless lambdas on gcc 5 and 6.
Additionally this adds a test case for the problem making use
of the proposed workaound.

Merge branch 'classnametest-no-demngling-fallback' into 'master'

ref:core/dune-common Run the classnametest is now run two times:

-   classnametest-demangled: skipped if __cxa_demangle() is missing
-   classnametest-fallback: an exit-status of 1 (resulting from failed checks
    expecting demangling) is still considered successfull, though anything
    else (e.g. segfault) will fail the test.

Closes: [#160]

See merge request [!666]

  [#160]: gitlab.dune-project.org/NoneNone/issues/160
  [!666]: gitlab.dune-project.org/core/dune-common/merge_requests/666


Closes #160

Run the classnametest is now run two times:
- `classnametest-demangled`: skipped if `__cxa_demangle()` is missing
- `classnametest-fallback`: an exit-status of 1 (resulting from failed checks
  expecting demangling) is still considered successfull, though anything
  else (e.g. segfault) will fail the test.

Merge branch 'dynamic-classname' into 'master'

ref:core/dune-common In addition, allow rvalue expr.

Closes: [#158]

WIP:

-   [x] This is somewhat of an interface change. Wait at least until
    2019-05-07 for comments
-   [x] Test for rvalue expr

See merge request [!659]

  [#158]: gitlab.dune-project.org/NoneNone/issues/158
  [!659]: gitlab.dune-project.org/core/dune-common/merge_requests/659


Closes #158

Merge branch 'issue/non_initialized_reservedvector' into 'master'

ref:core/dune-common

### Summary

Fixes a warning of maybe not initialized member of ReservedVector

### Details

A default initialization of a ReservedVector, i.e.

    ReservedVector<double,3> vec;
    vec.push_back(1.0);
    vec.back() = 2.0;

might result in a compiler warning about possible use of uninitialized members
vec.data[0]. This can be fixed with a default constructor and default member
initializers.

See merge request [!663]

  [!663]: gitlab.dune-project.org/core/dune-common/merge_requests/663

Merge branch 'introduce-lfe-variant' into 'master'

ref:core/dune-common Our own fallback implementation of Std::visit is
currently not compatible with visitors returning lvalues. This is needed for
the LocalFiniteElementVariant MR in dune-localfunctions. Notice that this also
avoids an allocation that was used in Std::visit before.

For the record: A further cleanup could optimize Hybrid::switchCase to use a
real c switch statement, because there's rumors that compiler can optimize
this much better than an `if ... else {} if...` sequence (current
implementation) or an array of fuction pointers (another possible visit
implementation).

See merge request [!664]

  [!664]: gitlab.dune-project.org/core/dune-common/merge_requests/664

Merge branch 'feature/deprecate-old-metis-parmetis' into 'master'

See merge request [!657]

  [!657]: Nonecore/dune-common/merge_requests/657

Merge branch 'bugfix/fix-id' into 'master'

ref:core/dune-common There's a bug in the current implementation of
Dune::Hybrid::Impl::Id. Trying to do 'perfect forwarding' using

      template<class T>
      constexpr decltype(auto) foo()(T&& x) {
        return std::forward<T>(x);
      }

leads to undefined behaviour if you pass an r-value to the function. Then
decltype(auto) would be deduced to be an r-value reference such that in

      auto&& bar = foo(expression());

bar would be bound to a temporary which is no longer alive because there's no
lifetime prolongation. The correct version is

      template<class T>
      constexpr T foo()(T&& x) {
        return std::forward<T>(x);
      }

When passed an r-value of the raw type E then T is deduced to be E such that
we move the temporary into the new value bar. If we pass an l-value of the raw
type E, then T is deduced to be either T& or `const T&` such that we properly
return the reference.

See merge request [!665]

  [!665]: gitlab.dune-project.org/core/dune-common/merge_requests/665

There's a bug in the current implementation of `Dune::Hybrid::Impl::Id`.
Trying to do 'perfect forwarding' using

  template<class T>
  constexpr decltype(auto) foo()(T&& x) {
    return std::forward<T>(x);
  }

leads to undefined behaviour if you pass an r-value
to the function. Then `decltype(auto)` would be
deduced to be an r-value reference such that in

  auto&& bar = foo(expression());

`bar` would be bound to a temporary which is no longer
alive because there's no lifetime prolongation. The correct
version is

  template<class T>
  constexpr T foo()(T&& x) {
    return std::forward<T>(x);
  }

When passed an r-value of the raw type `E` then `T` is
deduced to be `E` such that we move the temporary into
the new value `bar`. If we pass an l-value of the raw
type `E`, then `T` is deduced to be either `T&` or
`const T&` such that we properly return the reference.

Merge branch 'simd-ignore-vectorclass-value-initialization-issues' into 'master'

ref:core/dune-common Value-initialized Vectorclass simd types are not always
initialized. The reason is that vectorclass defines default-constructors for
its Simd types with empty body and no member initializers.
Value-initialization will see those constructors and invoke
default-initialization. As the mask types sometimes just contain an
`unsigned short` or similar fundamental data type, default-initializing that
does nothing and leaves it inintialized.

To make value-initialization work reliably, vectorclass would need to do one
of two things:

-   Make sure the default-constructor is implicitly or explicitly defaulted.
    That would mean value-initialization would invoke zero-initialization
    before default-inizialization, which would clear the member
-   Provide a default initializer when declaring the member, which would then
    be used when the class does not define an initializer for the member in
    the default-constructor's member-initializer-list.

Since I can't really fix vectorclass, work around this issue by using
direct-initialization with an initializer (Simd::Scalar<V>(0)) to initialize
simd types.

Closes: [extensions/dune-vectorclass#9]

See merge request [!662]

  [extensions/dune-vectorclass#9]: gitlab.dune-project.org/extensions/dune-vectorclass/issues/9
  [!662]: gitlab.dune-project.org/core/dune-common/merge_requests/662


Closes extensions/dune-vectorclass#9

Value-initialized Vectorclass simd types are not always initialized.  The
reason is that vectorclass defines default-constructors for its Simd types
with empty body and no member initializers.  Value-initialization will see
those constructors and invoke default-initialization.  As the mask types
sometimes just contain an `unsigned short` or similar fundamental data type,
default-initializing that does nothing and leaves it inintialized.

To make value-initialization work reliably, vectorclass would need to do one
of two things:
- Make sure the default-constructor is implicitly or explicitly defaulted.
  That would mean value-initialization would invoke zero-initialization before
  default-inizialization, which would clear the member
- Provide a default initializer when declaring the member, which would then be
  used when the class does not define an initializer for the member in the
  default-constructor's member-initializer-list.

Since I can't really fix vectorclass, work around this issue by using
direct-initialization with an initializer `(Simd::Scalar<V>(0))` to
initialize simd types.

Closes: extensions/dune-vectorclass#9

Merge branch 'bugfix/addparameterizedobjecttocmakelists' into 'master'

See merge request [!661]

  [!661]: Nonecore/dune-common/merge_requests/661

Merge branch 'missing-cxa-demangle-skips-classnametest' into 'master'

ref:core/dune-common Partially addresses [#160]

See merge request [!660]

  [#160]: gitlab.dune-project.org/NoneNone/issues/160
  [!660]: gitlab.dune-project.org/core/dune-common/merge_requests/660

Partially addresses #160

This is needed to avoid several instances of the helper conflicting with each
other during linking.

Alternatively, the helper could be put into the library (but it is kind of
small for that).  Or it could be made `static`, though I'm unsure whether it's
OK to call an internal linkage function from an inline function (`className()`
is implicitly inline as it is a template).

Closes: #158

Merge branch 'test-classname' into 'master'

ref:core/dune-common Previously it was only printed and the test could
basically never fail.

Addresses: [#158]

See merge request [!658]

  [#158]: gitlab.dune-project.org/NoneNone/issues/158
  [!658]: gitlab.dune-project.org/core/dune-common/merge_requests/658