December 17, 2010
1. I can reproduce in Windows.
2. I noticed that only that exact set of parameters causes the problem  (any set
of one or two of those parameters does not fail)
3. I have *no clue* about the source of the error.  The message appears to
originate from the std.process.shell function (which I'm guessing could
potentially be inlined?), but there are no calls to the shell function in your
program either directly or indirectly (phobos has only one call to shell in any
code, and that is in a std.process unit test that I verified is not being
compiled).
4. Do you need both -release and -noboundscheck?  I thought -noboundscheck was
implied with -release, no?  At least this might get you running again for now, I
agree we shouldn't ignore this bug though.


Without being able to understand the reason the compiler chooses to compile shell, I can't really determine how to fix it (it does seem like a compiler bug to me).  Don maybe has found a minimal case?

I don't think there is an error in appender or put, the following code compiles and runs fine with all the given parameters:

import std.array;
import std.range;

void main() {
    Appender!string app;
    put(app, "hello".dup);
}

Which is in direct conflict with the error message which says:

C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static assert "Cannot put a char[] into a Appender!(string)"

Now, I found some interesting weirdness inside the std.range.put function.

I'll quote the put clause that is being used to insert the char[] into the appender with some additional printouts:

static if (hasMember!(R, "put") ||
    (isPointer!R && is(pointerTarget!R == struct) &&
     hasMember!(pointerTarget!R, "put")))
    {
        //================  I ADDDED THESE THREE LINES
        pragma(msg, "isArray = "~((isArray!R) ? "yes" : "no"));
        pragma(msg, "canAddElement = "~(is(typeof(r.put(e))) ? "yes" : "no"));
        pragma(msg, "canAddArray = "~(is(typeof(r.put((&e)[0..1]))) ? "yes" :
"no"));

        // commit to using the "put" method
        static if (!isArray!R && is(typeof(r.put(e))))
        {
            pragma(msg, "here " ~ __LINE__.stringof); //================== line
282, I added this
            r.put(e);
        }
        else static if (!isArray!R && is(typeof(r.put((&e)[0..1]))))
        {
            pragma(msg, "here " ~ __LINE__.stringof); //================== line
287 I added this
            r.put((&e)[0..1]);
        }
        else
        {
            static assert(false,
                    "Cannot put a "~E.stringof~" into a "~R.stringof); //
============== line 292
        }
    }

With my added pragma msg's, the compiler does not error(!), and instead prints this:

isArray = no
canAddElement = yes
canAddArray = yes
here 282
isArray = no
canAddElement = yes
canAddArray = yes
here 282
isArray = no
canAddElement = yes  <<< this is the "normally" failing case, see below
canAddArray = no
here 282
isArray = no
canAddElement = yes
canAddArray = no
here 282

If I comment out the pragma(msg) that prints 'canAddArray', the error occurs:

isArray = no
canAddElement = yes
here 282
isArray = no
canAddElement = yes
here 282
isArray = no
canAddElement = no  <<< note the difference from the non-error run!!!!
C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static assert
"Cannot put a char[] into a Appender!(string)"
C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(985):        instantiated from
here: put!(Appender!(string),char[])
C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(1579):        instantiated
from here: formatValue!(Appender!(string),uint,immutable(char))
C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(306):        instantiated from
here: formatGeneric!(Appender!(string),uint,immutable(char))
C:\dmd2\windows\bin\..\..\src\phobos\std\process.d(339):        instantiated
from here: formattedWrite!(Appender!(string),immutable(char),uint)

So I'm not sure what to take away from this except in these specific conditions, the compiler has a bug.  What causes the problem, I'm not sure.  I tried reordering the pragmas, but it does not matter.

I can't really do anything to fix this, it has to be a compiler fix.  If you ask me, this smells like a memory corruption issue (the unprovoked call to shell, things changing just by reading them, etc.).

-Steve


----- Original Message ----
> From: Stephan Dilly <Dilly at Funatics.de>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Sent: Thu, December 16, 2010 7:02:23 PM
> Subject: Re: [dmd-beta] dmd 2.051 beta
> 
> i don't know why but it still does not build with the same errors here. maybe a win32 only issue ? can someone reproduce this under windows ? it happens in almost all my projects when trying to build with these parameters.



December 17, 2010
I see this is a very weird problem but i have the same errors with my current code base even at some placed when i do not use -release -inline -noboundscheck and that makes this release unusable for me if it stays like this. problem is that i cannot reduce it to a small testcase case .. if i change a bit (and the codebase is big) it suddenly disappears.

I think it is a major issue especially because it smells like mem corruption or something and it should not be shipped like that.


On 17.12.2010 17:25, Steve Schveighoffer wrote:
> 1. I can reproduce in Windows.
> 2. I noticed that only that exact set of parameters causes the problem  (any set
> of one or two of those parameters does not fail)
> 3. I have *no clue* about the source of the error.  The message appears to
> originate from the std.process.shell function (which I'm guessing could
> potentially be inlined?), but there are no calls to the shell function in your
> program either directly or indirectly (phobos has only one call to shell in any
> code, and that is in a std.process unit test that I verified is not being
> compiled).
> 4. Do you need both -release and -noboundscheck?  I thought -noboundscheck was
> implied with -release, no?  At least this might get you running again for now, I
> agree we shouldn't ignore this bug though.
>
>
> Without being able to understand the reason the compiler chooses to compile shell, I can't really determine how to fix it (it does seem like a compiler bug to me).  Don maybe has found a minimal case?
>
> I don't think there is an error in appender or put, the following code compiles and runs fine with all the given parameters:
>
> import std.array;
> import std.range;
>
> void main() {
>      Appender!string app;
>      put(app, "hello".dup);
> }
>
> Which is in direct conflict with the error message which says:
>
> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static assert
> "Cannot put a char[] into a Appender!(string)"
>
> Now, I found some interesting weirdness inside the std.range.put function.
>
> I'll quote the put clause that is being used to insert the char[] into the appender with some additional printouts:
>
> static if (hasMember!(R, "put") ||
>      (isPointer!R&&  is(pointerTarget!R == struct)&&
>       hasMember!(pointerTarget!R, "put")))
>      {
>          //================  I ADDDED THESE THREE LINES
>          pragma(msg, "isArray = "~((isArray!R) ? "yes" : "no"));
>          pragma(msg, "canAddElement = "~(is(typeof(r.put(e))) ? "yes" : "no"));
>          pragma(msg, "canAddArray = "~(is(typeof(r.put((&e)[0..1]))) ? "yes" :
> "no"));
>
>          // commit to using the "put" method
>          static if (!isArray!R&&  is(typeof(r.put(e))))
>          {
>              pragma(msg, "here " ~ __LINE__.stringof); //================== line
> 282, I added this
>              r.put(e);
>          }
>          else static if (!isArray!R&&  is(typeof(r.put((&e)[0..1]))))
>          {
>              pragma(msg, "here " ~ __LINE__.stringof); //================== line
> 287 I added this
>              r.put((&e)[0..1]);
>          }
>          else
>          {
>              static assert(false,
>                      "Cannot put a "~E.stringof~" into a "~R.stringof); //
> ============== line 292
>          }
>      }
>
> With my added pragma msg's, the compiler does not error(!), and instead prints
> this:
>
> isArray = no
> canAddElement = yes
> canAddArray = yes
> here 282
> isArray = no
> canAddElement = yes
> canAddArray = yes
> here 282
> isArray = no
> canAddElement = yes<<<  this is the "normally" failing case, see below
> canAddArray = no
> here 282
> isArray = no
> canAddElement = yes
> canAddArray = no
> here 282
>
> If I comment out the pragma(msg) that prints 'canAddArray', the error occurs:
>
> isArray = no
> canAddElement = yes
> here 282
> isArray = no
> canAddElement = yes
> here 282
> isArray = no
> canAddElement = no<<<  note the difference from the non-error run!!!!
> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static assert
> "Cannot put a char[] into a Appender!(string)"
> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(985):        instantiated from
> here: put!(Appender!(string),char[])
> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(1579):        instantiated
> from here: formatValue!(Appender!(string),uint,immutable(char))
> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(306):        instantiated from
> here: formatGeneric!(Appender!(string),uint,immutable(char))
> C:\dmd2\windows\bin\..\..\src\phobos\std\process.d(339):        instantiated
> from here: formattedWrite!(Appender!(string),immutable(char),uint)
>
> So I'm not sure what to take away from this except in these specific conditions, the compiler has a bug.  What causes the problem, I'm not sure.  I tried reordering the pragmas, but it does not matter.
>
> I can't really do anything to fix this, it has to be a compiler fix.  If you ask me, this smells like a memory corruption issue (the unprovoked call to shell, things changing just by reading them, etc.).
>
> -Steve
>
>
> ----- Original Message ----
>> From: Stephan Dilly<Dilly at Funatics.de>
>> To: Discuss the dmd beta releases for D<dmd-beta at puremagic.com>
>> Sent: Thu, December 16, 2010 7:02:23 PM
>> Subject: Re: [dmd-beta] dmd 2.051 beta
>>
>> i don't know why but it still does not build with the same errors here. maybe a win32 only issue ? can someone reproduce this under windows ? it happens in almost all my projects when trying to build with these parameters.
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

December 17, 2010
If that's the case (the problem occurs in some cases where that specific combination of flags isn't required), then I agree, we need to delay the release until this is fixed.

Walter, Don?

-Steve



----- Original Message ----
> From: Stephan Dilly <Dilly at funatics.de>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Sent: Fri, December 17, 2010 11:35:48 AM
> Subject: Re: [dmd-beta] dmd 2.051 beta
> 
> I see this is a very weird problem but i have the same errors with my current code base even at some placed when i do not use -release -inline -noboundscheck and that makes this release unusable for me if it stays like this. problem is that i cannot reduce it to a small testcase case .. if i change a bit (and the codebase is big) it suddenly  disappears.
> 
> I think it is a major issue especially because it smells like  mem corruption or something and it should not be shipped like  that.




December 17, 2010
Ok i made a mistake there i rechecked and found out that disabling
-noboundscheck everywhere in all my release builds makes the build
problem go away, there was some library i link still having this enabled
as it seems.
But I still do not like the idea to release a obviously regressed build.
That won't make the users pleased, me included though i now know the
workaround.


On 17.12.2010 17:35, Stephan Dilly wrote:
> I see this is a very weird problem but i have the same errors with my current code base even at some placed when i do not use -release -inline -noboundscheck and that makes this release unusable for me if it stays like this. problem is that i cannot reduce it to a small testcase case .. if i change a bit (and the codebase is big) it suddenly disappears.
>
> I think it is a major issue especially because it smells like mem corruption or something and it should not be shipped like that.
>
>
> On 17.12.2010 17:25, Steve Schveighoffer wrote:
>> 1. I can reproduce in Windows.
>> 2. I noticed that only that exact set of parameters causes the problem
>> (any set
>> of one or two of those parameters does not fail)
>> 3. I have *no clue* about the source of the error. The message appears to
>> originate from the std.process.shell function (which I'm guessing could
>> potentially be inlined?), but there are no calls to the shell function
>> in your
>> program either directly or indirectly (phobos has only one call to
>> shell in any
>> code, and that is in a std.process unit test that I verified is not being
>> compiled).
>> 4. Do you need both -release and -noboundscheck? I thought
>> -noboundscheck was
>> implied with -release, no? At least this might get you running again
>> for now, I
>> agree we shouldn't ignore this bug though.
>>
>>
>> Without being able to understand the reason the compiler chooses to
>> compile
>> shell, I can't really determine how to fix it (it does seem like a
>> compiler bug
>> to me). Don maybe has found a minimal case?
>>
>> I don't think there is an error in appender or put, the following code
>> compiles
>> and runs fine with all the given parameters:
>>
>> import std.array;
>> import std.range;
>>
>> void main() {
>> Appender!string app;
>> put(app, "hello".dup);
>> }
>>
>> Which is in direct conflict with the error message which says:
>>
>> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static
>> assert
>> "Cannot put a char[] into a Appender!(string)"
>>
>> Now, I found some interesting weirdness inside the std.range.put function.
>>
>> I'll quote the put clause that is being used to insert the char[] into
>> the
>> appender with some additional printouts:
>>
>> static if (hasMember!(R, "put") ||
>> (isPointer!R&& is(pointerTarget!R == struct)&&
>> hasMember!(pointerTarget!R, "put")))
>> {
>> //================ I ADDDED THESE THREE LINES
>> pragma(msg, "isArray = "~((isArray!R) ? "yes" : "no"));
>> pragma(msg, "canAddElement = "~(is(typeof(r.put(e))) ? "yes" : "no"));
>> pragma(msg, "canAddArray = "~(is(typeof(r.put((&e)[0..1]))) ? "yes" :
>> "no"));
>>
>> // commit to using the "put" method
>> static if (!isArray!R&& is(typeof(r.put(e))))
>> {
>> pragma(msg, "here " ~ __LINE__.stringof); //================== line
>> 282, I added this
>> r.put(e);
>> }
>> else static if (!isArray!R&& is(typeof(r.put((&e)[0..1]))))
>> {
>> pragma(msg, "here " ~ __LINE__.stringof); //================== line
>> 287 I added this
>> r.put((&e)[0..1]);
>> }
>> else
>> {
>> static assert(false,
>> "Cannot put a "~E.stringof~" into a "~R.stringof); //
>> ============== line 292
>> }
>> }
>>
>> With my added pragma msg's, the compiler does not error(!), and
>> instead prints
>> this:
>>
>> isArray = no
>> canAddElement = yes
>> canAddArray = yes
>> here 282
>> isArray = no
>> canAddElement = yes
>> canAddArray = yes
>> here 282
>> isArray = no
>> canAddElement = yes<<< this is the "normally" failing case, see below
>> canAddArray = no
>> here 282
>> isArray = no
>> canAddElement = yes
>> canAddArray = no
>> here 282
>>
>> If I comment out the pragma(msg) that prints 'canAddArray', the error
>> occurs:
>>
>> isArray = no
>> canAddElement = yes
>> here 282
>> isArray = no
>> canAddElement = yes
>> here 282
>> isArray = no
>> canAddElement = no<<< note the difference from the non-error run!!!!
>> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static
>> assert
>> "Cannot put a char[] into a Appender!(string)"
>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(985): instantiated from
>> here: put!(Appender!(string),char[])
>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(1579): instantiated
>> from here: formatValue!(Appender!(string),uint,immutable(char))
>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(306): instantiated from
>> here: formatGeneric!(Appender!(string),uint,immutable(char))
>> C:\dmd2\windows\bin\..\..\src\phobos\std\process.d(339): instantiated
>> from here: formattedWrite!(Appender!(string),immutable(char),uint)
>>
>> So I'm not sure what to take away from this except in these specific
>> conditions,
>> the compiler has a bug. What causes the problem, I'm not sure. I tried
>> reordering the pragmas, but it does not matter.
>>
>> I can't really do anything to fix this, it has to be a compiler fix.
>> If you ask
>> me, this smells like a memory corruption issue (the unprovoked call to
>> shell,
>> things changing just by reading them, etc.).
>>
>> -Steve
>>
>>
>> ----- Original Message ----
>>> From: Stephan Dilly<Dilly at Funatics.de>
>>> To: Discuss the dmd beta releases for D<dmd-beta at puremagic.com>
>>> Sent: Thu, December 16, 2010 7:02:23 PM
>>> Subject: Re: [dmd-beta] dmd 2.051 beta
>>>
>>> i don't know why but it still does not build with the same errors here. maybe a win32 only issue ? can someone reproduce this under windows ? it happens in almost all my projects when trying to build with these parameters.
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

December 18, 2010
It's not a DMD regression. With the DMD from 1.050 with the recent
Phobos, shows the same behaviour.
So, the compiler itself has not regressed.
I think a minor change to Phobos has triggered an instance of bug 4269.
I completely commented out std.process and replaced it with

import std.array;

void bugshell()
{
    auto a = appender!string();
    char[] g;
//    static assert (is(typeof(a.put(g))));
    a.put(g);
}

and it continues to reproduce the bug. If you replace "char[]" with
"string", the error goes away.
I'm still working on tracking this down.


On 17 December 2010 23:00, Stephan Dilly <Dilly at funatics.de> wrote:
> Ok i made a mistake there i rechecked and found out that disabling
> -noboundscheck everywhere in all my release builds makes the build problem
> go away, there was some library i link still having this enabled as it
> seems.
> But I still do not like the idea to release a obviously regressed build.
> That won't make the users pleased, me included though i now know the
> workaround.
>
>
> On 17.12.2010 17:35, Stephan Dilly wrote:
>>
>> I see this is a very weird problem but i have the same errors with my current code base even at some placed when i do not use -release -inline -noboundscheck and that makes this release unusable for me if it stays like this. problem is that i cannot reduce it to a small testcase case .. if i change a bit (and the codebase is big) it suddenly disappears.
>>
>> I think it is a major issue especially because it smells like mem corruption or something and it should not be shipped like that.
>>
>>
>> On 17.12.2010 17:25, Steve Schveighoffer wrote:
>>>
>>> 1. I can reproduce in Windows.
>>> 2. I noticed that only that exact set of parameters causes the problem
>>> (any set
>>> of one or two of those parameters does not fail)
>>> 3. I have *no clue* about the source of the error. The message appears to
>>> originate from the std.process.shell function (which I'm guessing could
>>> potentially be inlined?), but there are no calls to the shell function
>>> in your
>>> program either directly or indirectly (phobos has only one call to
>>> shell in any
>>> code, and that is in a std.process unit test that I verified is not being
>>> compiled).
>>> 4. Do you need both -release and -noboundscheck? I thought
>>> -noboundscheck was
>>> implied with -release, no? At least this might get you running again
>>> for now, I
>>> agree we shouldn't ignore this bug though.
>>>
>>>
>>> Without being able to understand the reason the compiler chooses to
>>> compile
>>> shell, I can't really determine how to fix it (it does seem like a
>>> compiler bug
>>> to me). Don maybe has found a minimal case?
>>>
>>> I don't think there is an error in appender or put, the following code
>>> compiles
>>> and runs fine with all the given parameters:
>>>
>>> import std.array;
>>> import std.range;
>>>
>>> void main() {
>>> Appender!string app;
>>> put(app, "hello".dup);
>>> }
>>>
>>> Which is in direct conflict with the error message which says:
>>>
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static
>>> assert
>>> "Cannot put a char[] into a Appender!(string)"
>>>
>>> Now, I found some interesting weirdness inside the std.range.put function.
>>>
>>> I'll quote the put clause that is being used to insert the char[] into
>>> the
>>> appender with some additional printouts:
>>>
>>> static if (hasMember!(R, "put") ||
>>> (isPointer!R&& is(pointerTarget!R == struct)&&
>>> hasMember!(pointerTarget!R, "put")))
>>> {
>>> //================ I ADDDED THESE THREE LINES
>>> pragma(msg, "isArray = "~((isArray!R) ? "yes" : "no"));
>>> pragma(msg, "canAddElement = "~(is(typeof(r.put(e))) ? "yes" : "no"));
>>> pragma(msg, "canAddArray = "~(is(typeof(r.put((&e)[0..1]))) ? "yes" :
>>> "no"));
>>>
>>> // commit to using the "put" method
>>> static if (!isArray!R&& is(typeof(r.put(e))))
>>> {
>>> pragma(msg, "here " ~ __LINE__.stringof); //================== line
>>> 282, I added this
>>> r.put(e);
>>> }
>>> else static if (!isArray!R&& is(typeof(r.put((&e)[0..1]))))
>>> {
>>> pragma(msg, "here " ~ __LINE__.stringof); //================== line
>>> 287 I added this
>>> r.put((&e)[0..1]);
>>> }
>>> else
>>> {
>>> static assert(false,
>>> "Cannot put a "~E.stringof~" into a "~R.stringof); //
>>> ============== line 292
>>> }
>>> }
>>>
>>> With my added pragma msg's, the compiler does not error(!), and
>>> instead prints
>>> this:
>>>
>>> isArray = no
>>> canAddElement = yes
>>> canAddArray = yes
>>> here 282
>>> isArray = no
>>> canAddElement = yes
>>> canAddArray = yes
>>> here 282
>>> isArray = no
>>> canAddElement = yes<<< this is the "normally" failing case, see below
>>> canAddArray = no
>>> here 282
>>> isArray = no
>>> canAddElement = yes
>>> canAddArray = no
>>> here 282
>>>
>>> If I comment out the pragma(msg) that prints 'canAddArray', the error
>>> occurs:
>>>
>>> isArray = no
>>> canAddElement = yes
>>> here 282
>>> isArray = no
>>> canAddElement = yes
>>> here 282
>>> isArray = no
>>> canAddElement = no<<< note the difference from the non-error run!!!!
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\range.d(292): Error: static
>>> assert
>>> "Cannot put a char[] into a Appender!(string)"
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(985): instantiated from
>>> here: put!(Appender!(string),char[])
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(1579): instantiated
>>> from here: formatValue!(Appender!(string),uint,immutable(char))
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\format.d(306): instantiated from
>>> here: formatGeneric!(Appender!(string),uint,immutable(char))
>>> C:\dmd2\windows\bin\..\..\src\phobos\std\process.d(339): instantiated
>>> from here: formattedWrite!(Appender!(string),immutable(char),uint)
>>>
>>> So I'm not sure what to take away from this except in these specific
>>> conditions,
>>> the compiler has a bug. What causes the problem, I'm not sure. I tried
>>> reordering the pragmas, but it does not matter.
>>>
>>> I can't really do anything to fix this, it has to be a compiler fix.
>>> If you ask
>>> me, this smells like a memory corruption issue (the unprovoked call to
>>> shell,
>>> things changing just by reading them, etc.).
>>>
>>> -Steve
>>>
>>>
>>> ----- Original Message ----
>>>>
>>>> From: Stephan Dilly<Dilly at Funatics.de>
>>>> To: Discuss the dmd beta releases for D<dmd-beta at puremagic.com>
>>>> Sent: Thu, December 16, 2010 7:02:23 PM
>>>> Subject: Re: [dmd-beta] dmd 2.051 beta
>>>>
>>>> i don't know why but it still does not build with the same errors here. maybe a win32 only issue ? can someone reproduce this under windows ? it happens in almost all my projects when trying to build with these parameters.
>>>
>>>
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
December 18, 2010

Don Clugston wrote:
> It's not a DMD regression. With the DMD from 1.050 with the recent
> Phobos, shows the same behaviour.
> So, the compiler itself has not regressed.
> I think a minor change to Phobos has triggered an instance of bug 4269.
> I completely commented out std.process and replaced it with
>
> import std.array;
>
> void bugshell()
> {
>     auto a = appender!string();
>     char[] g;
> //    static assert (is(typeof(a.put(g))));
>     a.put(g);
> }
>
> and it continues to reproduce the bug. If you replace "char[]" with
> "string", the error goes away.
> I'm still working on tracking this down.
>
> 

It's also not a memory corruption problem. I can reproduce the same issue on Linux (by rewriting std.process.shell so the windows version compiles on Linux). I don't remember seeing a memory corruption problem have exactly the same result on Linux and Windows.
December 18, 2010

Don Clugston wrote:
> It's not a DMD regression. With the DMD from 1.050 with the recent
> Phobos, shows the same behaviour.
> So, the compiler itself has not regressed.
> I think a minor change to Phobos has triggered an instance of bug 4269.
> I completely commented out std.process and replaced it with
>
> import std.array;
>
> void bugshell()
> {
>     auto a = appender!string();
>     char[] g;
> //    static assert (is(typeof(a.put(g))));
>     a.put(g);
> }
>
> and it continues to reproduce the bug. If you replace "char[]" with
> "string", the error goes away.
> I'm still working on tracking this down.
>
> 

I found two issues with valgrind, but neither is the source of the problem. I don't think it's memory corruption.
December 19, 2010
Ok, this is a *very* hard problem to track down, as it is subtly dependent on the order of instantiations. The problem is that std.array.Appender has 3 put() member templates. We are only concerned with the first and last one. If we pass an argument of type:

    char[]

to put(), it winds up tripping the recursive constraint detection in template.c, causing the constraint to fail, and the put() template is not instantiated.

The recursive part is not actually in the template constraint, it is in the body of put(). So it only happens when semantic3() is called on the template instantiation while inside the constraint of another instantiation. The reason for the erratic nature of the bug happening is that if semantic3() has already been called for the instantiation, it isn't called again. Also, sometimes the call to semantic3() is deferred to another module, or is deferred for other reasons, and so the error doesn't happen.

I thought about fixing the template so it wasn't recursive, but then thought this mysterious error would crop up elsewhere and confound the next person. So that was out. I still thought it best to eagerly attempt to do semantic3(). But bugzilla 4072 is the reason for the recursive protection code in the first place.

Finally, I decided upon a rather hackish solution - let the recursion detection code run a couple times before it trips. It doesn't seem right, but I can't think of anything better at the moment.
December 20, 2010
http://ftp.digitalmars.com/dmd2beta.zip

This should fix Stephan Dilly's issue.
December 20, 2010
Are you sure you uploaded a new archive, i get all the same errors still. even with my posted test case on this mailing list. Even the win32 dmd binary in it dates 15th of Dec

On 20.12.2010 09:32, Walter Bright wrote:
>
> http://ftp.digitalmars.com/dmd2beta.zip
>
> This should fix Stephan Dilly's issue.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>