Thread overview
[Issue 20180] Deprecated unittests should not be deprecated functions
Aug 29, 2019
FeepingCreature
Feb 26, 2020
Mathias LANG
Feb 26, 2020
Mathias LANG
Feb 26, 2020
FeepingCreature
Feb 26, 2020
Mathias LANG
Dec 17, 2022
Iain Buclaw
August 29, 2019
https://issues.dlang.org/show_bug.cgi?id=20180

--- Comment #1 from FeepingCreature <default_357-line@yahoo.de> ---
(This issue has come up in dmd nightly because deprecations from nested functions and mixins used to be ignored, which allowed unit-threaded to work without complaint.)

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20180

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pro.mathias.lang@gmail.com

--- Comment #2 from Mathias LANG <pro.mathias.lang@gmail.com> ---
What about using `__traits(isDeprecated)` ?

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20180

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20180

--- Comment #3 from FeepingCreature <default_357-line@yahoo.de> ---
I mean, it'll still be deprecated. The problem isn't determining whether a unittest is deprecated, the problem is calling it from a nondeprecated function.

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20180

--- Comment #4 from Mathias LANG <pro.mathias.lang@gmail.com> ---
Oh right. Yeah we probably need a way for framework to handle deprecated.
I wonder if it should be limited to unittests, or extended.
For example you could have a fuzzing framework that iterates over functions and
generate fuzzing code. You don't want to stop testing functions as soon as
they're deprecated, but you don't want to trigger the message either.

For the moment, a possible workaround is:
```
import std.traits;

deprecated @safe pure unittest
{

}

string funAttrToString (uint attrs)
{
    string result;
    if (attrs & FunctionAttribute.pure_)
        result ~= " pure";
    if (attrs & FunctionAttribute.nothrow_)
        result ~= " nothrow";
    if (attrs & FunctionAttribute.property)
        result ~= " @property";
    if (attrs & FunctionAttribute.trusted)
        result ~= " @trusted";
    if (attrs & FunctionAttribute.safe)
        result ~= " @safe";
    if (attrs & FunctionAttribute.nogc)
        result ~= " @nogc";
    if (attrs & FunctionAttribute.system)
        result ~= " @system";
    if (attrs & FunctionAttribute.const_)
        result ~= " const";
    if (attrs & FunctionAttribute.immutable_)
        result ~= " immutable";
    if (attrs & FunctionAttribute.inout_)
        result ~= " inout";
    if (attrs & FunctionAttribute.shared_)
        result ~= " shared";
    if (attrs & FunctionAttribute.return_)
        result ~= " return";
    return result;
}

void main () @safe pure
{
    static foreach (ut; __traits(getUnitTests, mixin(__MODULE__)))
    {
        static if (__traits(isDeprecated, ut))
        {
            mixin(`extern(C) void `, ut.mangleof, `()`,
funAttrToString(functionAttributes!ut),`;`);
            typeof(&ut) workaround = &mixin(__traits(identifier, ut));
            workaround();
        }
        else
            ut();
    }
}
```

However this relies on the fact that using `ut` in `__traits(identifier)` and
`typeof` does not trigger a deprecation.
Perhaps simply extending `__traits(isDeprecated)` to support:
`__traits(isDeprecated, ut, () { doThis(); })` would be enough.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=20180

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--