[dmd-beta] dmd 2.051 beta

[Don Clugston]

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
>