Closes: #169

Closes: #168

Merge branch 'deprecate-make_unique-fallback' into 'master'

ref:core/dune-common Closes: [#97]

See merge request [!686]

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


Closes #97

Merge branch 'stop-using-binary_function' into 'master'

See merge request [!685]

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


Closes #167

DUNE now requires full C++14 support.

Closes: #97

Just provide the type aliases directly and mark them deprecated
following similar deprecations in C++17.

Closes: #167

Merge branch 'explicit-capture-for-this' into 'master'

ref:core/dune-common This addresses the following warnings from GCC 9:

    dune/common/test/testsuite.hh:78:30: warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]
    dune/common/test/testsuite.hh:99:30: warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]

See merge request [!684]

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

This addresses the following warnings from GCC 9:

    dune/common/test/testsuite.hh:78:30: warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]
    dune/common/test/testsuite.hh:99:30: warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]

Note that pre-C++20 does not allow to explicitly capture `this` when
the default capture is `=`.  So all captures need to be listed.

Merge branch 'simd-no-abi-warning2' into 'master'

ref:core/dune-common Change all by-value parameters to simd functions that
might be simd vectors or masks to const-ref parameters. This means they don't
have to be split into multiple simd registers if the current abi does not have
large enough registers, I'm guessing.

Closes: [#164] See also: [!607]

WIP:

-   [x] Manually verify the warnings are really gone.

See merge request [!683]

  [#164]: gitlab.dune-project.org/NoneNone/issues/164
  [!607]: gitlab.dune-project.org/NoneNone/merge_requests/607
  [!683]: gitlab.dune-project.org/core/dune-common/merge_requests/683


Closes #164

Change all by-value parameters to simd functions that might be simd vectors or
masks to const-ref parameters.  This means they don't have to be split into
multiple simd registers if the current abi does not have large enough
registers, I'm guessing.

Closes: #164
See also: !607

Merge branch 'vc-architecture-changelog' into 'master'

ref:core/dune-common Closes: [#163]

See merge request [!682]

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


Closes #163

Merge branch 'ensure-avx-test' into 'master'

ref:core/dune-common Closes: [#165]

WIP:

-   [x] ensure the Vc vector types really turn out to have the expected size
    (well, we check Vc implementation, but close enough)

See merge request [!680]

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


Closes #165

Other implementations should only be selected if the compiler is specifically
told to support them.

Merge branch 'stop-using-std-iterator' into 'master'

ref:core/dune-common Closes: [#166]

See merge request [!681]

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


Closes #166

Closes: #166

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.