On 07/02/2021 15.55, Marcin Jaczewski wrote:
> niedz., 7 lut 2021 o 14:46 Avi Kivity via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>> On 07/02/2021 13.37, Andrey Semashev via Std-Proposals wrote:
>>> On February 7, 2021 1:22:41 PM Avi Kivity via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>>
>>>> On 28/01/2021 13.34, Ville Voutilainen via Std-Proposals wrote:
>>>>> On Thu, 28 Jan 2021 at 13:06, Dominic Fandrey via Std-Proposals
>>>>> <std-proposals_at_[hidden]> wrote:
>>>>>> I recently ran into this issue:
>>>>>>
>>>>>> 1. Marked a set of legacy methods [[deprecated]]
>>>>>> 2. Unit tests no longer compile (we run -Wall -Werror of course)
>>>>>>
>>>>>> Of course I don't want to get rid of the unit tests before I get
>>>>>> rid of the
>>>>>> functions. So I was faced with two choices:
>>>>>>
>>>>>> 1. Create #ifdef #pragma soup for all 3 compilers that we use
>>>>>> 2. Remove [[deprecated]]
>>>>>>
>>>>>> The #ifdef #pragma soup needs to be updated every time a compiler
>>>>>> is added,
>>>>>> and it bloats the code and makes unit tests more difficult to read.
>>>>>> So I
>>>>>> went for option 2. As long as I cannot ignore [[deprecated]] in a
>>>>>> portable
>>>>>> manner I cannot use it.
>>>>>>
>>>>>> So my suggestion is:
>>>>>>
>>>>>> ```
>>>>>> [[deprecated("use: std::optional<std::size_t> size()")]]int
>>>>>> size(std::size_t & size);
>>>>>>
>>>>>>
>>>>>> bool test_size() {
>>>>>> std::size_t s{0};
>>>>>> return 0 == [[deprecated]]size(s) && s != 0;
>>>>>> }
>>>>> 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.
>>> I don't think that preprocessor is deprecated or its proper use should
>>> be judged or anything. A preprocessor based solution is fine if this
>>> tool is best fit for the job.
>>>
>>>
>>>
>> It does not work with modules. If I have a module that has a
>> [[deprecated]] declaration, no amount of preprocessor tricks in the
>> importing code will affect that declaration.
>>
>>
> But if you control implementation adding `MY_DEPRECATED` and you
> control the build of all modules (aka `-D???` compiler switch) then
> this will work.


It doesn't work. It disables the warning for all call sites, not just
the call site of the unit test.


Without modules, it works, because a header file is evaluated
independently in each translation unit. With modules, a declaration is
exactly the same in all call sites.


> Of course you can't affect macros of module from other module as this
> was one of the main goals of the model proposal.
> But this is not this case. Only problem would be that you will need to
> make a clear build of all modules when you change flags of
> compilation.


So, to unit test something I need to recompile everything?


Compile times are long enough already, and people like to test the code
that runs in production, not code that was specially compiled for the test.