[Dune-devel] How to proceed with deprecation of DUNE_UNUSED_PARAM?

[Christoph Grüninger]

Hi!

Thinking further about a smooth transition path for DUNE_UNUSED I
propose the following (extension of option 1):

* Deprecate the macro DUNE_UNUSED, no warning will be emitted.
* After Dune 2.8 we remove the CMake test, thus HAS_ATTRIBUTE_UNUSED
will be always undefined and DUNE_UNUSED has no effect.
* The user will get a warning for an unused variable and can investigate
the problem. There is no guarantee that the user will act, but it
increases the chances.
* After Dune 2.9 we remove the macro.

Any objections?

Bye
Christoph


Am 24.03.21 um 23:03 schrieb Christoph Grüninger:
> Dear Dune developers,
> 
> I want to get rid of our own macros that suppress unused variable and
> unused parameter warnings. C++17 provides the attribute [[maybe_unused]]
> and it can be used for both of our DUNE_UNUSED and DUNE_UNUSED_PARAM in
> a standard fashion without relying on compiler extensions or CMake checks.
> But there is a catch: GCC < 9.3 has a bug that marking the first
> argument of a constructor as maybe unused leads to a crash (bug 81429).
> Within the core modules, UG grid, typetree, and functions this
> constellation occurred only once.
> 
> How should I proceed?
> 
> 1. Working around the bug as in dune-geometry / dune-geometry!158. I
> would add this piece of information to the changelog. It would make the
> deprecation of the whole header smooth.
> 
> 2. Only deprecate DUNE_UNUSED and leave DUNE_UNUSED_PARAM as it is. In
> this case we cannot have deprecation warnings (possible for headers, not
> for macros).
> 
> We can get rid of the CMake checks after Dune 2.8 either way.
> 
> What do you think?
> 
> Discussion in the dune-common MR:
> https://gitlab.dune-project.org/core/dune-common/-/merge_requests/946#note_79045
> 
> Bye
> Christoph