www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Deprecation message sources

reply Steven Schveighoffer <schveiguy gmail.com> writes:
Hi,

I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores 
of deprecation messages. One thing I've realized is that most of these 
messages are generated by calls outside my code. These deprecation 
messages are intended to tell you where you are calling them, but end up 
telling you where phobos, or vibe.d, or whatever, is calling them.

For example, I get messages like:

home/steves/.dvm/compilers/dmd-2.088.0/linux/bin/../../src/phobos/st
/traits.d(3687,61): 
Deprecation: function std.typecons.Nullable!string.Nullable.get_ is 
deprecated - Implicit conversion with alias Nullable.get this will be 
removed after 2.096. Please use .get explicitly.

The line in question is commented below:

template hasElaborateAssign(S)
{
     static if (isStaticArray!S && S.length)
     {
         enum bool hasElaborateAssign = 
hasElaborateAssign!(typeof(S.init[0]));
     }
     else static if (is(S == struct))
     {
/***** the line below ****/
         enum hasElaborateAssign = 
is(typeof(S.init.opAssign(rvalueOf!S))) ||
 
is(typeof(S.init.opAssign(lvalueOf!S))) ||
             anySatisfy!(.hasElaborateAssign, FieldTypeTuple!S);
     }
     else
     {
         enum bool hasElaborateAssign = false;
     }
}

I'm not calling hasElaborateAssign from anywhere in my code. So 1. how 
am I supposed to know where this call is being generated from, and 2. 
I'm assuming this is happening inside a static if buried deep somewhere 
in library code, so how am I supposed to fix it?

I'd hate to say the answer is to special case Nullable for so many 
functions, but what other alternative is there?

-Steve
Sep 17 2019
next sibling parent reply Anonymouse <zorael gmail.com> writes:
On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven 
Schveighoffer wrote:

 I'd hate to say the answer is to special case Nullable for so 
 many functions, but what other alternative is there?

 -Steve


Nullable isn't alone, std.json.JSONType causes a literal wall of 
text of deprecation warnings.

import std.stdio;
import std.json;

void main()
{
     writeln(JSONValue.init.type);
}

https://run.dlang.io/is/J0UDay
Sep 17 2019
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/17/19 4:16 PM, Anonymouse wrote:

 On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer wrote:

 I'd hate to say the answer is to special case Nullable for so many 
 functions, but what other alternative is there?

 -Steve


 
 Nullable isn't alone, std.json.JSONType causes a literal wall of text of 
 deprecation warnings.
 
 import std.stdio;
 import std.json;
 
 void main()
 {
      writeln(JSONValue.init.type);
 }
 
 https://run.dlang.io/is/J0UDay


I mean, I'm OK with the idea, but having these deprecation messages is 
helping nobody. I can't figure out if there's something I'm supposed to, 
or can, change in order to get rid of them.

There are quite a few places where it is flagging my code for Nullable 
usage without get, and I'm fixing those. But I'll still be left with 
this mess of deprecation messages from Phobos and vibe.d. I don't even 
know where or if it will break once the alias this is removed.

-Steve
Sep 17 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via 
Digitalmars-d-learn wrote:

 On 9/17/19 4:16 PM, Anonymouse wrote:

 On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer 




wrote:

 I'd hate to say the answer is to special case Nullable for so many
 functions, but what other alternative is there?

 -Steve


 Nullable isn't alone, std.json.JSONType causes a literal wall of text of
 deprecation warnings.

 import std.stdio;
 import std.json;

 void main()
 {

      writeln(JSONValue.init.type);

 }

 https://run.dlang.io/is/J0UDay


 I mean, I'm OK with the idea, but having these deprecation messages is
 helping nobody. I can't figure out if there's something I'm supposed to,
 or can, change in order to get rid of them.

 There are quite a few places where it is flagging my code for Nullable
 usage without get, and I'm fixing those. But I'll still be left with
 this mess of deprecation messages from Phobos and vibe.d. I don't even
 know where or if it will break once the alias this is removed.


I ran into problems along those lines with dxml recently, and I couldn't
figure out why one of the deprecation messages was being triggered. It
seemed to have to do with isInputRange, but I couldn't figure out where in
my code was resulting in that problem. I tried to track it down by compiling
Phobos with the alias this outright removed from Nullable (with the idea
that I'd then hopefully get some decent error messages wherever the real
problem was), and dxml's tests then compiled and ran just fine with no
deprecation messages. So, I don't know what to do about it. I suspect that
deprecation messages are being triggered simply by code trying to use
Nullable in template constraints rather than just when it's actually used in
proper code, but I don't know.

I ran into problems along those lines when I last tried to deprecate
TickDuration (which is why it's not yet deprecated). Template constraints
were triggering deprecation messages when I didn't think that they should
be, but unfortunately, I didn't have time to narrow down what was going on
so that I could create a proper bug report for it, and I haven't gotten back
to it.

- Jonathan M Davis
Sep 17 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/17/19 8:14 PM, Jonathan M Davis wrote:

 On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via
 Digitalmars-d-learn wrote:

 On 9/17/19 4:16 PM, Anonymouse wrote:

 On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer




 wrote:

 I'd hate to say the answer is to special case Nullable for so many
 functions, but what other alternative is there?

 -Steve


 Nullable isn't alone, std.json.JSONType causes a literal wall of text of
 deprecation warnings.

 import std.stdio;
 import std.json;

 void main()
 {

       writeln(JSONValue.init.type);

 }

 https://run.dlang.io/is/J0UDay


 I mean, I'm OK with the idea, but having these deprecation messages is
 helping nobody. I can't figure out if there's something I'm supposed to,
 or can, change in order to get rid of them.

 There are quite a few places where it is flagging my code for Nullable
 usage without get, and I'm fixing those. But I'll still be left with
 this mess of deprecation messages from Phobos and vibe.d. I don't even
 know where or if it will break once the alias this is removed.


 
 I ran into problems along those lines with dxml recently, and I couldn't
 figure out why one of the deprecation messages was being triggered. It
 seemed to have to do with isInputRange, but I couldn't figure out where in
 my code was resulting in that problem. I tried to track it down by compiling
 Phobos with the alias this outright removed from Nullable (with the idea
 that I'd then hopefully get some decent error messages wherever the real
 problem was), and dxml's tests then compiled and ran just fine with no
 deprecation messages. So, I don't know what to do about it. I suspect that
 deprecation messages are being triggered simply by code trying to use
 Nullable in template constraints rather than just when it's actually used in
 proper code, but I don't know.


I too, think that it's really the template constraints that are causing 
so much grief. Not only that, but it's impossible to find the code 
that's actually triggering the usage.

Maybe the best idea then is to use a version. In other words, you 
compile your code with version=nullableRequiresGet, and then it aliases 
Nullable to a new type (to avoid symbol conflicts) that requires get 
without the deprecation? After the deprecation, just replace the alias 
with the real Nullable. Then at least you can update your code to get 
rid of all the deprecation messages.

-Steve
Sep 18 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 18, 2019 at 10:48:27AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:

 On 9/17/19 8:14 PM, Jonathan M Davis wrote:


[...]

 I suspect that deprecation messages are being triggered simply by
 code trying to use Nullable in template constraints rather than just
 when it's actually used in proper code, but I don't know.


 
 I too, think that it's really the template constraints that are
 causing so much grief. Not only that, but it's impossible to find the
 code that's actually triggering the usage.


That's really annoying.  Why are constraints triggering deprecation
messages?  Shouldn't it be actual usage that trigger them?

I've also seen similar in my own projects, and it's an eyesore, esp.
since it was Phobos code that was triggering the messages, not actually
anything in my own code.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Sep 18 2019
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/18/19 11:09 AM, H. S. Teoh wrote:

 On Wed, Sep 18, 2019 at 10:48:27AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:

 On 9/17/19 8:14 PM, Jonathan M Davis wrote:


 [...]

 I suspect that deprecation messages are being triggered simply by
 code trying to use Nullable in template constraints rather than just
 when it's actually used in proper code, but I don't know.


 I too, think that it's really the template constraints that are
 causing so much grief. Not only that, but it's impossible to find the
 code that's actually triggering the usage.


 
 That's really annoying.  Why are constraints triggering deprecation
 messages?  Shouldn't it be actual usage that trigger them?


Well, if the constraint is going to change the result when the symbol is 
actually removed, I'd say yes.

For example:

foo(int);

Nullable!int x;

static if(is(typeof(foo(x))) // true before removal, false after

But of course, my call isn't going to be that, that's going to be buried 
somewhere deep in a template.


 I've also seen similar in my own projects, and it's an eyesore, esp.
 since it was Phobos code that was triggering the messages, not actually
 anything in my own code.


Yeah, I would like to see where the deprecation is being triggered in MY 
code. I don't think -de will work, because then it simply changes what 
the is-expression returns, rather than show me the full trace of what I 
was trying to instantiate.

Really annoying.

-Steve
Sep 18 2019
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 17 September 2019 at 20:16:12 UTC, Anonymouse wrote:

 On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven 
 Schveighoffer wrote:

 I'd hate to say the answer is to special case Nullable for so 
 many functions, but what other alternative is there?

 -Steve


 Nullable isn't alone, std.json.JSONType causes a literal wall 
 of text of deprecation warnings.

 import std.stdio;
 import std.json;

 void main()
 {
     writeln(JSONValue.init.type);
 }

 https://run.dlang.io/is/J0UDay


Wow. How come this is not caught by the CI testing?

-Johan
Sep 17 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Sep 17, 2019 at 08:55:27PM +0000, Johan Engelen via Digitalmars-d-learn
wrote:
[...]

 Wow. How come this is not caught by the CI testing?


[...]

Is the CI setup to detect deprecations and flag them as failures?

It's either that, or many cases are not tested because Phobos has a lot
of templates, not all of which are instantiated with the specific
combination of template arguments that triggers deprecation messages.


T

-- 
Without outlines, life would be pointless.
Sep 17 2019
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 17, 2019 5:28:33 PM MDT H. S. Teoh via Digitalmars-d-
learn wrote:

 On Tue, Sep 17, 2019 at 08:55:27PM +0000, Johan Engelen via
 Digitalmars-d-learn wrote: [...]


 Wow. How come this is not caught by the CI testing?


 [...]

 Is the CI setup to detect deprecations and flag them as failures?

 It's either that, or many cases are not tested because Phobos has a lot
 of templates, not all of which are instantiated with the specific
 combination of template arguments that triggers deprecation messages.


Yes. Seb made druntime and Phobos compile with -de a while back in order to
make sure that all cases where deprecations pop up actually get fixed - but
of course, that's only going to catch the cases that are in the tests, and
it probably wouldn't be hard to trigger a bunch of deprecations in Phobos by
doing something like using a range of Nullable, since implicit conversions
would probably get triggered all over the place - especially if it's the
case that the deprecation message gets triggered by stuff like static if
tests and template constraints (I'm not sure that it does in this case, but
I have seen problems in the past where template constraints triggered
deprecation messages; last time I tried to deprecate TickDuration, I ran
into a bunch of problems like that, which is why it hasn't been deprecated
yet).

- Jonathan M Davis
Sep 17 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-09-17 22:55, Johan Engelen wrote:


 Wow. How come this is not caught by the CI testing?


That issue seems to be because "writeln" is printing "type", which is an 
enum. For enums, "writeln" prints the actual name of the enum member and 
not the value. It seems it extracts the names of all enum members and 
this particular enum contains deprecated members.

-- 
/Jacob Carlborg
Sep 18 2019
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/17/19 3:31 PM, Steven Schveighoffer wrote:

 Hi,
 
 I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores 
 of deprecation messages. One thing I've realized is that most of these 
 messages are generated by calls outside my code. These deprecation 
 messages are intended to tell you where you are calling them, but end up 
 telling you where phobos, or vibe.d, or whatever, is calling them.


Bug in compiler?

void foo(int y)
{
}

void main()
{
   Nullable!int x = 5;
   assert(x > 0); // No deprecation warning
   foo(x); // deprecation warning
}

Using -vcg-ast, it is indeed calling the _get function in both cases.

-Steve
Sep 17 2019