On 07/02/2021 15:36, Avi Kivity via Std-Proposals wrote:
>
> On 07/02/2021 16.28, Ville Voutilainen wrote:
>> On Sun, 7 Feb 2021 at 12:22, Avi Kivity <avi_at_[hidden]> wrote:
>>>> Create your own MY_DEPRECATED macro, make it expand to actual
>>>> deprecation normally, but not in unit tests,
>>>> compile the unit tests with -DMY_SOMETHING that disables deprecations.
>>>> Or just add a #define into
>>>> your unit tests.
>>> Doesn't that break with modules?
>>> We should not be suggesting solutions that involve the preprocessor in 2021.
>> Fair point. When the attribute is a property of a real declaration,
>> text-processing techniques no longer help.
>>
>> I wonder whether we should go for a [[nowarn]] instead that just turns
>> off diagnostics that don't report
>> ill-formedness.
>
>
> That's a heavy hammer. I prefer more selective tools. For example, I wouldn't want a [[nodiscard]] warning discarded in a call site where I meant to shut down a [[deprecated]] warning.
>
>
> Perhaps [[nowarn(deprecated)]].
>
>
>> If I had that, I would certainly hop on my time
>> machine and make it available on every
>> C++11 compiler I've ever used. :)
>
>
> An approach that I've seen working is to make developer builds use -Werror, but user builds omit it. This way developers of a project have to battle the warnings (and suffer when a new compiler is released), but users are able to compile the project regardless of the compiler/platform combination (at least if warnings are the only problem).

Generally I wouldn't want to turn off the warning for all unit tests, not even for
a whole test (after all I want to keep my unit tests up to date). I would prefer
something that affects a single statement.