Merge branch 'duneproject-check-deps' into 'master'

ref:core/dune-common Fixes:

-   Use unambiguous truth values (Closes: [#134])
-   When checking with pkg-config, look for the dependency rather than the
    last module from the list of found modules

Modernizations:

-   Scope variables
-   Use a simple if rather than a loop to check for presence of a depency in
    list of existing modules
-   Make sure the function does not depend on the status of the -e option, or
    whether it is called from within the condition of an if or a || or &&.

Documentation:

-   Document calling convention for the function and assumptions on the
    parameters.

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

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


Closes #134

Merge branch 'feature/add-transformedrangeview' into 'master'

ref:core/dune-common This adds a TransformedRangeView and a helper function
transformedRangeView() creating it.

This behaves like a range providing begin() and end(). The iterators over this
range internally iterate over the wrapped range. When dereferencing the
iterator, the value is transformed on-the-fly using a given transformation
function leaving the underlying range unchanged.

The transformation may either return temorary values or l-value references. In
the former case the range behaves like a proxy-container. In the latter case
it forwards these references allowing, e.g., to sort a subset of some
container by applying a transformation to an index-range for those values.

The iterators of the TransformedRangeView have the same iterator_category as
the ones of the wrapped container.

If the wrapped range is an r-value, then the TransformedRangeView stores it by
value, if the wrapped range is an l-value, then the TransformedRangeView
stores it by reference.

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

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

Member functions returning iterators need to be overwritten
in the derived interator class. Otherwise they would return
base class iterators.

Here we duplicate the implementations. This could be avoided
using CRTP and/or mixins. However, this would lead to more
complicated and even longer code.

This behaves like a range providing `begin()` and `end()`.
The iterators over this range internally iterate over
the wrapped range. When dereferencing the iterator,
the value is transformed on-the-fly using a given
transformation function leaving the underlying range
unchanged.

The transformation may either return temorary values
or l-value references. In the former case the range behaves
like a proxy-container. In the latter case it forwards these
references allowing, e.g., to sort a subset of some container
by applying a transformation to an index-range for those values.

The iterators of the `TransformedRangeView` have the same
`iterator_category` as the ones of the wrapped container.

If the wrapped range is an r-value, then the TransformedRangeView stores it by value,
if the wrapped range is an l-value, then the TransformedRangeView stores it by reference.

Merge branch 'bugfix/fix-varianttest-with-libc++' into 'master'

ref:core/dune-common When using clang with libc++, the vector header does not
get pulled in implicitly by some part of the standard library, causing
compilation of varianttest to fail.

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

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

When using clang with libc++, the vector header does not get pulled in implicitly
by some part of the standard library, causing compilation of varianttest to fail.

Fixes:
- Use unambiguous truth values (Closes: #134)
- When checking with pkg-config, look for the dependency rather than the last
  module from the list of found modules

Modernizations:
- Scope variables
- Use a simple `if` rather than a loop to check for presence of a depency in
  list of existing modules
- Make sure the function does not depend on the status of the `-e` option, or
  whether it is called from within the condition of an `if` or a `||` or `&&`.

Documentation:
- Document calling convention for the function and assumptions on the
  parameters.

Merge branch 'feature/add-uniquetypes-helper' into 'master'

ref:core/dune-common For a given `template<class...> Target` and list of types
T... the alias `UniqueTypes_t<Target, T...>` refers the instatiated template
Target<S...>, where S... is generated from T... by removing duplicate types.

This is useful for std::variant, because duplicate types are not fully
supported by some implementations. If your type list is generated by whatever
mechanism where you don't have control over uniqueness, then
`UniqueTypes_t<std::variant, T...>` is what std::variant<T...> should have
been.

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

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

For a given `template<class...> Target` and list of types `T...`
the alias `UniqueTypes_t<Target, T...>`  refers the instatiated
template `Target<S...>`, where `S...` is generated from `T...`
by removing duplicate types.

This is useful for `std::variant`, because duplicate types
are not fully supported by some implementations. If your
type list is generated by whatever mechanism where you don't
have control over uniqueness, then `UniqueTypes_t<std::variant, T...>`
is what `std::variant<T...>` should have been.

This would fit into `typetraits.hh`. However, this would lead
to a cyclic dependency of `typetraits.hh` and `std/type_traits.hh`.
Hence I've put it into `typelist.hh` which conceptually also
deals with type list, altough no `TypeList<...>` shows up
in the interface of `UniqueTypes_t`.

Merge branch 'duneproject-fix-indent' into 'master'

ref:core/dune-common As a shell script, duneproject is not covered by the
scripts preventing tabs in indentation (or simply was exempt from the Great
Reformatting). Also, the tab width was inconsistent.

This expands all tabs and uses a consistent indentation of 2. It also
instructs both emacs and vi to use these settings, since their default
indentation for shell scripts seems to differ.

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

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

As a shell script, duneproject is not covered by the scripts preventing tabs
in indentation (or simply was exempt from the Great Reformatting).  Also, the
tab width was inconsistent.

This expands all tabs and uses a consistent indentation of 2.  It also
instructs both emacs and vi to use these settings, since their default
indentation for shell scripts seems to differ.

Merge branch 'feature/fix-iteratortest' into 'master'

ref:core/dune-common

-   While testForwardIterator() prints to std::cerr its result was ignored in
    testBidirectionalIterator() such that a failure in the former would still
    lead to a passed test. Now we also capture errors in
    testForwardIterator().
-   testBidirectionalIterator() returned on the first error. Now we continue
    the test to potentially find more errors at once.
-   Fix requirements on forward iterators. C++14 does *not* require that two
    iterators compare equal if they are default-initialized, but only if they
    are value-initialized. This makes a difference for POD types: Raw pointers
    are valid forward iterators (used e.g. in std::array) since
    value-initialization zero-initializes them, altough default-initialization
    would leave them uninitialized.

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

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

* While testForwardIterator() prints to std::cerr its result
  was ignored in testBidirectionalIterator() such that a failure
  in the former would still lead to a passed test. Now we also
  capture errors in testForwardIterator().
* testBidirectionalIterator() returned on the first error. Now we
  continue the test to potentially find more errors at once.
* Fix requirements on forward iterators. C++14 does _not_ require
  that two iterators compare equal if they are default-initialized,
  but only if they are value-initialized. This makes a difference
  for POD types: Raw pointers are valid forward iterators (used e.g.
  in std::aray) since value-initialization zero-initializes them,
  altough default-initialization would leave them uninitialized.

Merge branch 'feature/fix-integralrangeiterator-default-constructor' into 'master'

ref:core/dune-common In c++-14 all value-initilized forward iterators should
behave like the end-iterator of a hypothetic empty container and furthermore
should all compare equal. Here, this would lead to undefined behaviour since
the value_ member is not initialized.

To avoid this we no initilize it by 0 which mimics 'past end of empty range'.
With this patch we can check IntegralRangeInterator using the
testConstIterator() test suite.

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

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

In c++-14 all value-initilized forward iterators
should behave like the end-iterator of a hypothetic
empty container and furthermore should all compare equal.
Here, this would lead to undefined behaviour since
the `value_` member is not initialized.

To avoid this we no initilize it by 0 which mimics
'past end of empty range'

This currently leads to undefined behaviour because
comparison of default constructed iterators uses
uninitialized values.

Merge branch 'feature/improve-variant' into 'master'

ref:core/dune-common

-   Implement and use a cmake check instead of __has_include(<variant>)
    because `g++-7 -std=c++14` defines the header but not std::variant
-   Pull std::monostate into the Dune::Std:: namespace and provide a fallback
    implementation.

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

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

* Use cmake check instead of `__has_include(<variant>)`
  because `g++-7 -std=c++14` defines the header but not `std::variant`
* Pull `std::monostate` into the Dune::Std:: namespace
  and provide a fallback implementation.

Using `__has_include(<variant>)` unfortunately does not
work as expected, because for `g++-7 -std=c++14` the
`variant` header exists but does not define `std::variant`

Merge branch 'document-std-variant' into 'master'

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

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

Merge branch 'feature/stdvariant' into 'master'

ref:core/dune-common In dune-subgrid we wanted to use std::variant which is
part of C++17's STL ([see e.g. here]). Since the corresponding compilers (or
rather STL implementations) aren't too widespread by now and also out of pure
curiosity, I reimplemented std::variant myself using only C++14 and some of
Dune::Hybrid. In the end I ended up with a implementation that covers most of
the STL functionality and behaves more or less the same way (though it
probably won't be as safe, fast or complete as e.g. the gcc implementation, of
course). If this might be of any value for the Dune project, I'd be happy to
contribute this to dune-common.

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

  [see e.g. here]: http://en.cppreference.com/w/cpp/utility/variant
  [core/dune-common!342]: gitlab.dune-project.org/core/dune-common/merge_requests/342

Merge branch 'minimum-vc-version-on-clang7+' into 'master'

ref:core/dune-common Close: [#132]

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

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


Closes #132

This is to appease cmake 3.5.1 on Ubuntu 16.04

Close: #132

Merge branch 'fix-typos' into 'master'

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

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

Merge branch 'BitSetVector-add-documentation-and-implement-reset' into 'master'

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

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

They are not included in the generated API documentation otherwise.

Merge branch 'ci/fix-test-labels' into 'master'

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

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

All of the other modules don't specify the quick label on their tests.

Merge branch 'ci/centralize-config' into 'master'

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

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

The special vectorization test run stays in the local configuration, as it is specific to
dune-common.

Merge branch 'ci/clang-7' into 'master'

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

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

Merge branch 'feature/std-negation' into 'master'

ref:core/dune-common This implements c++17's std::negation in namespace
Dune::Std::

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

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