dmd 1.069 and 2.054 release

[Jonathan M Davis]

On Monday 11 July 2011 13:16:59 Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > The deprecation messages are pragmas. They _can't_ give a useful
> > line number.
> 
> My "solution" is to replace the pragma with a static assert(0) so
> the compiler gives an error and call trace.
> 
> /home/me/d/dmd2/linux/bin32/../../src/phobos/std/string.d(885): Error:
> static assert  (0) is false
> arsd/web.d(575):        instantiated from here: tolower!(string)
> [snip]
> 
> 
> static assert(0) is actually my go-to replacement when things
> start to go belly up, especially with templates. The list of
> instantiated from here lines is a huge help when figuring it
> all out.
> 
> 
> Anyway, the pragma is meant to be informative and the assert is
> an error. But, there's an easy "fix" for that too.
> 
> In std.string there's a softDeprec template. I think this is new
> and it's private to std.string, but it's great because we can
> add:
> 
> 	version(scheduled_for_deprecation_is_an_error)
> 		static assert(0);
> 
> Thus:
> ===
> private template softDeprec(string vers, string date, string oldFunc, string
> newFunc) {
> 	version(scheduled_for_deprecation_is_an_error)
> 		static assert(0);
>     enum softDeprec = Format!("Warning: As of Phobos %s, std.string.%s has
> been scheduled " ~
> ===
> 
> 
> And then you get a full error with details upon request.
> 
> 
> (btw I keep putting fix and such in quotes because this is a filthy
> hack!)

I created softDeprec to make it easier to make the pragma messages (and to 
ensure that they're consistent). I believe that both std.string and std.file 
have one, and the idea is that once they're no longer needed, they'll go away.

The version idea is an interesting one, but I'm not sure if it helps much. The 
error message would give the file and line number of the pragma, not where the 
function was used. And what you really need to know is where the function was 
used so that you can track it down and replace it. If it gives you  stack 
trace though, I guess that it would help, though it would certainly be ugly. 
Fortunately, in the case of something like tolower, _every_ function called 
tolower is scheduled for deprecation (unless you created one in your own 
code), so simply searching for it in your code will locate the ones that need 
to be replaced, but still, the current situation is less than ideal.

What we really need is something like what I was discussing with Daniel - an 
improvement to the deprecated attribute so that it can be used in this kind of 
situation. Then it can become an actual compiler warning, though it wouldn't 
exactly be a normal one, since a function which has only been scheduled for 
deprecation should never cause the compilation to fail because it's used.

- Jonathan M Davis