www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD front end should define a version containing the front end version

reply "SiegeLord" <none none.com> writes:
I am quite sick of DMDFE breaking my code every release with bugs
that are then solved for the next release (that is, if they are
solved). If I track the latest compiler, then my code is broken
for older compilers (and you are kidding yourselves if you think
people always use the latest DMDFE/DMDFE from git). I want DMDFE
to define a version identifier so I can provide version specific
workarounds and/or disable features so that my code at least
compiles for each DMDFE.

__traits(compiles,) is not sufficient, as some bugs that are
crippling my code right now are ICE's.

Detecting the compiler version during the build process is not
sufficient, as I'd have to force my build process onto everybody
who uses my code.

The only way to do this right now, I think, is to look for added
features (because every DMDFE keeps adding features... soon we'll
have all the features)... but this is awkward.

Seriously... D compiler development process will not get better
and you will keep adding bugs to it that break people's code. At
least make it easier for people to cope with this nonsense.

I probably can implement this myself, but I'd like some assurance
that it will be merged before I write an enhancement request on
bugzilla and waste time implementing it. Maybe this feature is
already available and I'm not aware of it?
Feb 24 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/24/2013 05:48 PM, SiegeLord wrote:
...
 (because every DMDFE keeps adding features... soon we'll have all the
features)...
 ...

You realize that you are complaining about this in a feature request? :o)
 Maybe this feature is already available and I'm not aware of it?

static assert(__VERSION__==2060);
Feb 24 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/24/2013 06:00 PM, SiegeLord wrote:
 On Sunday, 24 February 2013 at 16:54:20 UTC, Timon Gehr wrote:
 You realize that you are complaining about this in a feature request? :o)

Using D requires doublethink.

For the moment I'm just sticking with 2.060, because I have failed to reduce all the forward reference regressions introduced in 2.061.
 Maybe this feature is already available and I'm not aware of it?

static assert(__VERSION__==2060);

This works, but is it documented? I have been burned (in this most recent DMD version no less) by undocumented features being removed.

The documentation is often wrong anyway, but here you go: http://dlang.org/lex.html (look for 'Special Tokens')
Feb 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2013 9:05 AM, Timon Gehr wrote:
 For the moment I'm just sticking with 2.060, because I have failed to reduce
all
 the forward reference regressions introduced in 2.061.

I've found dustmite to be pretty helpful reducing things down.
Feb 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/24/2013 11:22 PM, Walter Bright wrote:
 On 2/24/2013 9:05 AM, Timon Gehr wrote:
 For the moment I'm just sticking with 2.060, because I have failed to
 reduce all
 the forward reference regressions introduced in 2.061.

I've found dustmite to be pretty helpful reducing things down.

The problem is that there are many other spurious errors emitted and dustmite finds reduced code that is not valid, but still emits the same forward reference error. Fixing the other compile errors then also gets rid of the forward reference error. So I am quite certain that the original problem is not exposed by the reduced code any more.
Feb 24 2013
prev sibling next sibling parent "SiegeLord" <none none.com> writes:
On Sunday, 24 February 2013 at 16:54:20 UTC, Timon Gehr wrote:
 You realize that you are complaining about this in a feature 
 request? :o)

Using D requires doublethink.
 Maybe this feature is already available and I'm not aware of 
 it?

static assert(__VERSION__==2060);

This works, but is it documented? I have been burned (in this most recent DMD version no less) by undocumented features being removed.
Feb 24 2013
prev sibling next sibling parent "SiegeLord" <none none.com> writes:
On Sunday, 24 February 2013 at 17:05:57 UTC, Timon Gehr wrote:
 The documentation is often wrong anyway, but here you go:

 http://dlang.org/lex.html

 (look for 'Special Tokens')

Hmm... it is documented as "Compiler version as an integer, such as 2001". I wouldn't except this to match the DMDFE version for anything except DMD, a priori. I observe that both GDC and LDC right now keep the same code (i.e. __VERSION__ does match the DMDFE version on those compilers) but, say, SDC has a version of 0. Frankly I'd except LDC to have a __VERSION__ of 0010 (or however they want to encode that) instead of 2060. Well, whatever... it is good enough for now. I'll isolate the version checking code and hope that GDC/LDC developers don't change the __VERSION__ code. I'm still up to implementing this if somebody with commit rights sees the hackiness of this.
Feb 24 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
http://dlang.org/phobos/std_compiler.html#Vendor
http://dlang.org/phobos/std_compiler.html#version_major

Although it might be nice if GDC/LDC carried the version number of the
DMDFE it was based on (If that would be applicable. I don't know if
they're always based on an exact release version of DMDFE.)
Feb 24 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2013 8:48 AM, SiegeLord wrote:
 I am quite sick of DMDFE breaking my code every release with bugs
 that are then solved for the next release (that is, if they are
 solved).

Here's the current regression list: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Feb 24 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 24, 2013 14:22:42 Walter Bright wrote:
 On 2/24/2013 9:05 AM, Timon Gehr wrote:
 For the moment I'm just sticking with 2.060, because I have failed to
 reduce all the forward reference regressions introduced in 2.061.

I've found dustmite to be pretty helpful reducing things down.

I really need to figure out how to use dustmite one of these days. The last time that I tried to use it, I couldn't get it to work, but it may have been because rather than trying to find where the code stopped compiling, I was trying to find when the error message changed (the bug being encountered changed rather than a bug simply being introduced). - Jonathan M Davis
Feb 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf3074b900fccfe804d682122c
Content-Type: text/plain; charset=ISO-8859-1

On Feb 24, 2013 10:41 PM, "Timon Gehr" <timon.gehr gmx.ch> wrote:
 On 02/24/2013 11:22 PM, Walter Bright wrote:
 On 2/24/2013 9:05 AM, Timon Gehr wrote:
 For the moment I'm just sticking with 2.060, because I have failed to
 reduce all
 the forward reference regressions introduced in 2.061.

I've found dustmite to be pretty helpful reducing things down.

The problem is that there are many other spurious errors emitted and

forward reference error. Fixing the other compile errors then also gets rid of the forward reference error. So I am quite certain that the original problem is not exposed by the reduced code any more. Might be... No, I AM pointing out the obvious, but use 'git bisect' instead! Maybe someone should write a nice handy D app that works like dustmite, but instead of reduces code, interacts with gut instead to help automate finding the bad commit. :) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf3074b900fccfe804d682122c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 24, 2013 10:41 PM, &quot;Timon Gehr&quot; &lt;<a href=3D"mailto:timo= n.gehr gmx.ch">timon.gehr gmx.ch</a>&gt; wrote:<br> &gt;<br> &gt; On 02/24/2013 11:22 PM, Walter Bright wrote:<br> &gt;&gt;<br> &gt;&gt; On 2/24/2013 9:05 AM, Timon Gehr wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; For the moment I&#39;m just sticking with 2.060, because I hav= e failed to<br> &gt;&gt;&gt; reduce all<br> &gt;&gt;&gt; the forward reference regressions introduced in 2.061.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; I&#39;ve found dustmite to be pretty helpful reducing things down.= <br> &gt;<br> &gt;<br> &gt; The problem is that there are many other spurious errors emitted and d= ustmite finds reduced code that is not valid, but still emits the same forw= ard reference error. Fixing the other compile errors then also gets rid of = the forward reference error. So I am quite certain that the original proble= m is not exposed by the reduced code any more.</p> <p>Might be...=A0 No, I AM pointing out the obvious, but use &#39;git bisec= t&#39; instead! </p> <p>Maybe someone should write a nice handy D app that works like dustmite, = but instead of reduces code, interacts with gut instead to help automate fi= nding the bad commit.=A0 :)</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --20cf3074b900fccfe804d682122c--
Feb 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf3074afa84ca61c04d6821d12
Content-Type: text/plain; charset=ISO-8859-1

On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2 digitalmars.com>
wrote:
 On 2/24/2013 8:48 AM, SiegeLord wrote:
 I am quite sick of DMDFE breaking my code every release with bugs
 that are then solved for the next release (that is, if they are
 solved).

Here's the current regression list:


All regressions should have a link to the commit where the issue first recurred. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf3074afa84ca61c04d6821d12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 24, 2013 10:16 PM, &quot;Walter Bright&quot; &lt;<a href=3D"mailto:n= ewshound2 digitalmars.com">newshound2 digitalmars.com</a>&gt; wrote:<br> &gt;<br> &gt; On 2/24/2013 8:48 AM, SiegeLord wrote:<br> &gt;&gt;<br> &gt;&gt; I am quite sick of DMDFE breaking my code every release with bugs<= br> &gt;&gt; that are then solved for the next release (that is, if they are<br=

&gt;<br> &gt;<br> &gt; Here&#39;s the current regression list:<br> &gt;<br> &gt; <a href=3D"http://d.puremagic.com/issues/buglist.cgi?query_format=3Dad= vanced&amp;bug_severity=3Dregression&amp;bug_status=3DNEW&amp;bug_status=3D= ASSIGNED&amp;bug_status=3DREOPENED">http://d.puremagic.com/issues/buglist.c= gi?query_format=3Dadvanced&amp;bug_severity=3Dregression&amp;bug_status=3DN= EW&amp;bug_status=3DASSIGNED&amp;bug_status=3DREOPENED</a><br> &gt;</p> <p>All regressions should have a link to the commit where the issue first r= ecurred.<br></p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --20cf3074afa84ca61c04d6821d12--
Feb 24 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 24, 2013 at 02:55:07PM -0800, Jonathan M Davis wrote:
 On Sunday, February 24, 2013 14:22:42 Walter Bright wrote:
 On 2/24/2013 9:05 AM, Timon Gehr wrote:
 For the moment I'm just sticking with 2.060, because I have failed
 to reduce all the forward reference regressions introduced in
 2.061.

I've found dustmite to be pretty helpful reducing things down.

I really need to figure out how to use dustmite one of these days. The last time that I tried to use it, I couldn't get it to work, but it may have been because rather than trying to find where the code stopped compiling, I was trying to find when the error message changed (the bug being encountered changed rather than a bug simply being introduced).

I started using dustmite a few days ago, and it's dead simple to use. Just put your source code in some directory, say src, then construct a command (or shell script) that returns exit status 0 if said code still exhibits the problem you're trying to minimize, non-zero otherwise. Then just run 'dustmite src $command', and it takes care of the rest. Having said that, though, constructing the script can be a bit tricky, depending on what bug you're trying to isolate. Like you said, simply running dmd may not be enough (the compile error could have changed, etc.). So you probably need to use grep -qF to grep for the exact error message you're trying to isolate, and specifically test for that. T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Feb 24 2013
prev sibling next sibling parent "Don" <turnyourkidsintocash nospam.com> writes:
On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:
 On Feb 24, 2013 10:16 PM, "Walter Bright" 
 <newshound2 digitalmars.com>
 wrote:
 On 2/24/2013 8:48 AM, SiegeLord wrote:
 I am quite sick of DMDFE breaking my code every release with 
 bugs
 that are then solved for the next release (that is, if they 
 are
 solved).

Here's the current regression list:


All regressions should have a link to the commit where the issue first recurred.

In my experience, that's nearly always a waste of time. In almost all cases, there is nothing wrong with the offending commit, it merely triggered an existing latent bug. This is particularly true of forward reference bugs. Knowing what the commit was, that exposed the bug, does not help at all in fixing it. It's enough to know one commit where it worked, and one where it failed, in order to be certain that it's a regression. OTOH making sure that the test case is truly minimal, is a huge help in fixing the bug.
Feb 25 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf3074afa8b65bc404d689bab5
Content-Type: text/plain; charset=ISO-8859-1

On 25 February 2013 09:35, Don <turnyourkidsintocash nospam.com> wrote:

 On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:

 On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2 digitalmars.com>
 wrote:

 On 2/24/2013 8:48 AM, SiegeLord wrote:

 I am quite sick of DMDFE breaking my code every release with bugs
 that are then solved for the next release (that is, if they are
 solved).

Here's the current regression list: http://d.puremagic.com/issues/**buglist.cgi?query_format=**

status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>

recurred.

In my experience, that's nearly always a waste of time. In almost all cases, there is nothing wrong with the offending commit, it merely triggered an existing latent bug. This is particularly true of forward reference bugs.

does help to give a reference point on where to start looking for tracing the different code paths down and find a resolution to the regression, as opposed to "removing this line" or "adding this safegaurd seems to work". Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf3074afa8b65bc404d689bab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 5 February 2013 09:35, Don <span dir=3D"ltr">&lt;<a href=3D"mailto:turnyour= kidsintocash nospam.com" target=3D"_blank">turnyourkidsintocash nospam.com<= /a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Monday, 25 February 201= 3 at 01:04:01 UTC, Iain Buclaw wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Feb 24, 2013 10:16 PM, &quot;Walter Bright&quot; &lt;<a href=3D"mailto:n= ewshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com</a>= &gt;<br> wrote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> On 2/24/2013 8:48 AM, SiegeLord wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I am quite sick of DMDFE breaking my code every release with bugs<br> that are then solved for the next release (that is, if they are<br> solved).<br> </blockquote> <br> <br> Here&#39;s the current regression list:<br> <br> <br> </blockquote> <a href=3D"http://d.puremagic.com/issues/buglist.cgi?query_format=3Dadvance= d&amp;bug_severity=3Dregression&amp;bug_status=3DNEW&amp;bug_status=3DASSIG= NED&amp;bug_status=3DREOPENED" target=3D"_blank">http://d.puremagic.com/iss= ues/<u></u>buglist.cgi?query_format=3D<u></u>advanced&amp;bug_severity=3D<u=
</u>regression&amp;bug_status=3DNEW&amp;bug_<u></u>status=3DASSIGNED&amp;b=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> </blockquote> <br></div></div><div class=3D"im"> All regressions should have a link to the commit where the issue first<br> recurred.<br> </div></blockquote> <br> In my experience, that&#39;s nearly always a waste of time. In almost<br> all cases, there is nothing wrong with the offending commit, it<br> merely triggered an existing latent bug. This is particularly<br> true of forward reference bugs.<br> <br></blockquote><div><br></div><div>I didn&#39;t imply that there was anyt= hing wrong with the offending commit.=A0 It does help to give a reference p= oint on where to start looking for tracing the different code paths down an= d find a resolution to the regression, as opposed to &quot;removing this li= ne&quot; or &quot;adding this safegaurd seems to work&quot;.<br> </div></div><br><br>Regards<br></div><div class=3D"gmail_extra">-- <br>Iain= Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --20cf3074afa8b65bc404d689bab5--
Feb 25 2013
prev sibling parent "Don" <turnyourkidsintocash nospam.com> writes:
On Monday, 25 February 2013 at 10:09:18 UTC, Iain Buclaw wrote:
 On 25 February 2013 09:35, Don 
 <turnyourkidsintocash nospam.com> wrote:

 On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:

 On Feb 24, 2013 10:16 PM, "Walter Bright" 
 <newshound2 digitalmars.com>
 wrote:

 On 2/24/2013 8:48 AM, SiegeLord wrote:

 I am quite sick of DMDFE breaking my code every release 
 with bugs
 that are then solved for the next release (that is, if they 
 are
 solved).

Here's the current regression list: http://d.puremagic.com/issues/**buglist.cgi?query_format=**

status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>

issue first recurred.

In my experience, that's nearly always a waste of time. In almost all cases, there is nothing wrong with the offending commit, it merely triggered an existing latent bug. This is particularly true of forward reference bugs.

commit.

I didn't intend to imply that you did. My experience is that it doesn't even have any useful relationship to the bug, and that (even worse) you waste a lot of time trying to figure out what the relationship is.
 It
 does help to give a reference point on where to start looking 
 for tracing
 the different code paths down and find a resolution to the 
 regression, a
 opposed to "removing this line" or "adding this safegaurd seems 
 to work".

Intuitively, I used to think that, but I personally have not found that to be true in practice. I think tracking down the exact commit is a complete waste of time. In the cases I've seen where it had a clear relationship to the bug, it was obvious what part of the code contained the bug, anyway.
Feb 25 2013