deprecation warning for Topology classes

The deprecation of the Topology classes is not working as I would expect it to - but no idea how to fix it.

If you look at https://gitlab.dune-project.org/core/dune-geometry/-/jobs/234387 for example you'll see that warnings are being thrown all over the place although nothing in dune-geometry should be using these classes anymore. As far as I can see any inclusion of types.hh leads to multiple warnings. Same in dune-localfunction (https://gitlab.dune-project.org/core/dune-localfunctions/-/jobs/233937) and in dune-fem the CI output is truncated due to it becoming too large.

Any idea how to fix this?

I don't think that this can be fixed. DUNE_NO_DEPRECATED_* does not work at class scope and in specializations. But since this is in Impl:: it's fair to assume that this is used by experts only who follow the discussion. Hence only marking this deprecated in the documentation and release notes is IMO a viable option in this case.

I would suggest to remove the deprecation for this release since it really makes compiling with -Wall impossible. After the release we simply move the classes into a special topology.hh header which we mark as deprecated. That might break some code but would be easy to fix if somebody runs into any issue. Then we can simply remove that header later on (but it doesn't hurt a lot to have it there).

Why moving the classes we want to get rid of to a special header? If it breaks anyway, we can remove them right after Dune 2.8.

Because if we remove the depracation warnings there is no suitable deprecation period and have that header for a bit makes it easy for anyone to adapt when their code just breaks after the release without warning. So why wouldn't we do that?

It's inside Impl::, we never recommended its use and never promised that it might not break. We add a deprecation, ok, not a compiler warning, but fair enough. If it breaks, it should be fixed right away and not moved to another deprecated warning. If there is no time to fix it, the can locally revert the removing commit.

I don't get - we will need to remove the current deprecation warning from the compiler because it produces an insane amount of compiler output so there is not deprecation - except a message somewhere. I'm talking about having a file lying around in dune-geometry for a bit that is clearly deprecated at the top so that anyone who has been using this can simply add an include to keep code working for a bit longer. I'm happy to do it - what exactly is your issue with this?

I am fine with Andreas' suggestion. Andreas, would you mind submitting a merge request?

I'm also happy with the proposed approach.

See !167 (merged)

This issue persist, right? Only Clang is affected, GCC does not have this problem. This should be fixed for 2.8.

With clang I get

In file included from /dune/modules/dune-geometry/dune/geometry/type.hh:102:
/dune/modules/dune-geometry/dune/geometry/deprecated_topology.hh:142:76: warning: 'Point' is deprecated: Use GeometryTypes::vertex instead. [-Wdeprecated-declarations]
    template< template< class > class Operation, int dim, class Topology = Point >
                                                                           ^
/dune/modules/dune-geometry/dune/geometry/deprecated_topology.hh:12:14: note: 'Point' has been explicitly marked deprecated here
    struct [[deprecated("Use GeometryTypes::vertex instead.")]] Point
             ^

mentioned in merge request !168 (closed)

mentioned in merge request !178 (merged)

I think I came up with a solution, see !178 (merged). I renamed the struct Point and created an alias Point to the other structure. Only the alias is deprecated. To avoid the deprecation, on has to use the not-deprecated helper struct.

Is this a valid idea? Fine to merge?

mentioned in commit 36986ad8

closed with merge request !178 (merged)

mentioned in commit 005bddd4

mentioned in merge request !179 (merged)