Set the following variables always to 1:
 DUNE_HAVE_CXX_CLASS_TEMPLATE_ARGUMENT_DEDUCTION
 DUNE_HAVE_CXX_OPTIONAL
 DUNE_HAVE_CXX_VARIANT
 DUNE_SUPPORTS_CXX_THROW_IN_CONSTEXPR
 DUNE_HAVE_C_ALIGNED_ALLOC

Merge branch 'update-CI' into 'master'

See merge request [core/dune-common!786]

  [core/dune-common!786]: Nonecore/dune-common/merge_requests/786

Merge branch 'features/no-fortran' into 'master'

ref:core/dune-common\> FindLAPACK and FindBLAS check for the name mangling
with added underline as a fallback, anyway. Hence there is no need for using a
Fortran compiler. With this commit we now simply add another check for a
LAPACK function to see whether it has an underline added and adapt the
existing macro in config.h accordingly.

Closes [#184]

See merge request [core/dune-common!767]

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


Closes #184

Markus Blatt authored 5 years ago and Christoph Grüninger committed 5 years ago

FindLAPACK and FindBLAS check for the name mangling with added
underline as a fallback, anyway. Hence there is no need for using
a Fortran compiler. With this commit we now simply add another check
for a LAPACK function to see whether it has an underline added and
adapt the existing macro in config.h accordingly.

Closes #184

Merge branch 'feature/3d-eigenvalues+vectors' into 'master'

ref:core/dune-common\> When dealing with small matrices calling LAPACK to
calculate Eigenvalues and Eigenvectors can be quite slow. 1d- and
2d-specializations are quite straightforward, for the 3d-specialization I´m
using the approach presented in
[https://www.geometrictools.com/Documentation/RobustEigenSymmetric3x3.pdf].

See merge request [core/dune-common!776]

  [https://www.geometrictools.com/Documentation/RobustEigenSymmetric3x3.pdf]: https://www.geometrictools.com/Documentation/RobustEigenSymmetric3x3.pdf
  [core/dune-common!776]: gitlab.dune-project.org/core/dune-common/merge_requests/776

Merge branch 'loopsimd_alignment' into 'master'

ref:core/dune-common\> This MR remerges [!670], which was reverted due to to
much time and memory requirement for looptest. This MR merges the branch again
but with two changes:

-   It adds explicit instantiations to the looptest
-   It changes the default template argument of the alignment to 0, which
    means that it has no impact. In particular, if it is set to 0, rebound
    types have the template argument 0 as well. That reduces the number of
    types for that the tests are compiled and executed.

See merge request [core/dune-common!784]

  [!670]: gitlab.dune-project.org/NoneNone/merge_requests/670
  [core/dune-common!784]: gitlab.dune-project.org/core/dune-common/merge_requests/784

This reverts commit ebae92f0.

Merge branch 'revert-3c5922d7' into 'master'

ref:core/dune-common\> This reverts merge request [!670]

As explained by @carsten.graeser the compiler costs increased dramatically.
Let's revert this MR until we sorted out the actual problem and keep the
compile time in the usual bounds.

See merge request [core/dune-common!782]

  [!670]: gitlab.dune-project.org/NoneNone/merge_requests/670
  [core/dune-common!782]: gitlab.dune-project.org/core/dune-common/merge_requests/782

This reverts merge request !670

Merge branch 'loopsimd_alignment' into 'master'

ref:core/dune-common\> This MR adds a additional template parameter to
LoopSIMD to specify the alignment.

The default alignment is the alignment of the underlying type.

I'm not sure how to determine the proper alignment for some return types or
RebindType. To mitigate that problem I define conversion constructors and
assignment operators from LoopSIMD types with different alignment.

This MR depends on [!669].

Feel free to push at the source branch!

See merge request [core/dune-common!670]

  [!669]: gitlab.dune-project.org/NoneNone/merge_requests/669
  [core/dune-common!670]: gitlab.dune-project.org/core/dune-common/merge_requests/670

Merge branch 'loopsimd_for_vector_types' into 'master'

ref:core/dune-common\> This MR adapts LoopSIMD to take another vectorized type
as template argument. If Tis a vectorized type, then LoopSIMD<T,k> has
lanes<T>()*k lanes and the same scalar as T (Scalar<LoopSIMD<T,k>> ==
Scalar<T>).

This is useful with dune-vectorclass, to create arbitrary large vector types
with explicit SIMD support, for example.

Feel free to push any changes to the source branch!

See merge request [core/dune-common!669]

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

Merge branch 'fix-typo' into 'master'

See merge request [core/dune-common!778]

  [core/dune-common!778]: Nonecore/dune-common/merge_requests/778

Merge branch 'fix-implicit-this-capture' into 'master'

ref:core/dune-common C++20 deprecates implicit capture of this using [=], and
gcc9 warns about that. Unfortunately, in C++ before 20 listing this together
with a capture-default of = is illegal, and GCC 8 emits a warning about that
that apparently can't be silenced. So the only option if we want to appease
both pre- and post-C++20 is to list each entity to be captures explicitly.
Luckily, that is not too hard in this case.

See [https://gitlab.dune-project.org/core/dune-common/-/jobs/139584\#L486]
(debian:11 gcc-9-20):

    [ 40%] Building CXX object dune/common/CMakeFiles/dunecommon.dir/simd/test.cc.o
    In file included from /builds/core/dune-common/dune/common/simd/test.cc:6:
    /builds/core/dune-common/dune/common/simd/test.hh: In lambda function:
    /builds/core/dune-common/dune/common/simd/test.hh:334:36: warning: implicit capture of 'this' via '[=]' is deprecated in C++20 [-Wdeprecated]
      334 |         Hybrid::forEach(Rebinds{}, [=](auto target) {
          |                                    ^
    /builds/core/dune-common/dune/common/simd/test.hh:334:36: note: add explicit 'this' or '*this' capture

WIP:

-   [x] Check these warnings are really gone in the CI

See merge request [core/dune-common!775]

  [https://gitlab.dune-project.org/core/dune-common/-/jobs/139584\#L486]: https://gitlab.dune-project.org/core/dune-common/-/jobs/139584#L486
  [core/dune-common!775]: gitlab.dune-project.org/core/dune-common/merge_requests/775

C++20 deprecates implicit capture of `this` using `[=]`, and gcc9 warns about
that.  Unfortunately, in C++ before 20 listing `this` together with a
capture-default of `=` is illegal, and GCC 8 emits a warning about that that
apparently can't be silenced.  So the only option if we want to appease both
pre- and post-C++20 is to list each entity to be captures explicitly.
Luckily, that is not too hard in this case.

See https://gitlab.dune-project.org/core/dune-common/-/jobs/139584#L486
(debian:11 gcc-9-20):
```
[ 40%] Building CXX object dune/common/CMakeFiles/dunecommon.dir/simd/test.cc.o
In file included from /builds/core/dune-common/dune/common/simd/test.cc:6:
/builds/core/dune-common/dune/common/simd/test.hh: In lambda function:
/builds/core/dune-common/dune/common/simd/test.hh:334:36: warning: implicit capture of 'this' via '[=]' is deprecated in C++20 [-Wdeprecated]
  334 |         Hybrid::forEach(Rebinds{}, [=](auto target) {
      |                                    ^
/builds/core/dune-common/dune/common/simd/test.hh:334:36: note: add explicit 'this' or '*this' capture
```

Merge branch 'fix-warning-add-comments' into 'master'

ref:core/dune-common This is a regression test, the threw up undefined
variable warnings. unsure about the correct fix, I tried to understand the
test. In addition to fixing the warnings, I left some comments too, in the
hope future readers will have a little easier time understanding what it is
supposed to do.

The warnings showed up in
[https://gitlab.dune-project.org/core/dune-common/-/jobs/139437\#L665]
(debian:10 clang-7-libcpp-17):

    [ 60%] Building CXX object dune/common/test/CMakeFiles/fvectorconversion1d.dir/fvectorconversion1d.cc.o
    /builds/core/dune-common/dune/common/test/fvectorconversion1d.cc:86:16: warning: unused variable 'mfv' [-Wunused-variable]
          MiddleFV mfv;
                   ^
    /builds/core/dune-common/dune/common/test/fvectorconversion1d.cc:107:16: warning: unused variable 'mfv' [-Wunused-variable]
          MiddleFV mfv;
                   ^
    2 warnings generated.

See also: [!735], [!562]

See merge request [core/dune-common!773]

  [https://gitlab.dune-project.org/core/dune-common/-/jobs/139437\#L665]: https://gitlab.dune-project.org/core/dune-common/-/jobs/139437#L665
  [!735]: gitlab.dune-project.org/NoneNone/merge_requests/735
  [!562]: gitlab.dune-project.org/NoneNone/merge_requests/562
  [core/dune-common!773]: gitlab.dune-project.org/core/dune-common/merge_requests/773

This is a regression test, the threw up undefined variable warnings.  unsure
about the correct fix, I tried to understand the test.  In addition to fixing
the warnings, I left some comments too, in the hope future readers will have a
little easier time understanding what it is supposed to do.

The warnings showed up in
https://gitlab.dune-project.org/core/dune-common/-/jobs/139437#L665 (debian:10
clang-7-libcpp-17):
```
[ 60%] Building CXX object dune/common/test/CMakeFiles/fvectorconversion1d.dir/fvectorconversion1d.cc.o
/builds/core/dune-common/dune/common/test/fvectorconversion1d.cc:86:16: warning: unused variable 'mfv' [-Wunused-variable]
      MiddleFV mfv;
               ^
/builds/core/dune-common/dune/common/test/fvectorconversion1d.cc:107:16: warning: unused variable 'mfv' [-Wunused-variable]
      MiddleFV mfv;
               ^
2 warnings generated.
```

See also: !735, !562

Merge branch 'update-compiler-requirements' into 'master'

ref:core/dune-common According to dev meeting 2020-02

See merge request [core/dune-common!772]

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

According to dev meeting 2020-02

Merge branch 'function.hh-useful-deprecation' into 'master'

ref:core/dune-common Make the deprecation of function.hh more useful

-   Move it outside of inclusion guard so it triggers on every include (\#186)
-   #undef the disarming-define once it has suppressed a warning so the
    warning will fire again in the next include (\#186)
-   Mention the dune version in the warning so we know when we can finally
    remove it
-   deprecate also the individual classes and function in function.hh so it is
    easier to know what exactly to fix

See merge request [core/dune-common!769]

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

Deprecate the classes and functions in function.hh too, so it is easier to
tell what one needs to do to update a file when it throws warnings

Make it possible to tell at a glance when the deprecation was put into effect,
so we can know when we can remove the stuff.