Date: Sun, 7 Feb 2021 15:32:40 +0100
niedz., 7 lut 2021 o 15:07 Avi Kivity <avi_at_[hidden]> napisał(a):
>
>
> 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:
> >>>>> 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.
>
And what exactly is the problem there?
If this flag is used only for tests then we do not lose anything.
When you write code and build a final version this attribute is
present, and it will warn you.
Only unit test build will skip checking it.
>
> 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.
>
>
I only argue that this is possible and will work, not that it is a
good idea or should be done.
Beside right now you need to recompile everything for tests anyway if
you use diffrent macros.
Another observation that unit test compilation can be done in diffrent
folder (or even machines like CI/CD),
something like done by Visual Studio that have `bin/Debug`,
`bin/Release` and `obj/Debug`, `obj/Release' folders.
>
>
> 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:
> >>>>> 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.
>
And what exactly is the problem there?
If this flag is used only for tests then we do not lose anything.
When you write code and build a final version this attribute is
present, and it will warn you.
Only unit test build will skip checking it.
>
> 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.
>
>
I only argue that this is possible and will work, not that it is a
good idea or should be done.
Beside right now you need to recompile everything for tests anyway if
you use diffrent macros.
Another observation that unit test compilation can be done in diffrent
folder (or even machines like CI/CD),
something like done by Visual Studio that have `bin/Debug`,
`bin/Release` and `obj/Debug`, `obj/Release' folders.
Received on 2021-02-07 08:32:53