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 "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
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
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 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
next sibling parent reply 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
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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


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.

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';
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 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 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 parent reply 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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


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

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Feb 24 2013



  parent reply "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:


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


 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



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


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=**


 advanced&bug_severity=**regression&bug_status=NEW&bug_**
 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>



 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.


I didn't imply that there was anything wrong with the offending commit.  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, as
opposed to "removing this line" or "adding this safegaurd seems to work".


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Feb 25 2013



  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=**


 advanced&bug_severity=**regression&bug_status=NEW&bug_**
 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>



 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.


 I didn't imply that there was anything wrong with the offending 
 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