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?

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);

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.

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')

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.

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.)

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

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.

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.

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