http://d.puremagic.com/issues/show_bug.cgi?id=2702

           Summary: Declaring struct, assigning rvalue via opAssign in same
                    statement fails silently
           Product: D
           Version: 2.025
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: dsimcha@yahoo.com


import std.stdio;

struct Bar {
    uint num;

    Bar opAssign(uint otherNum) {
        num = otherNum;
        return this;
    }
}

void main() {
    Bar bar = 1;
    writeln(bar.num);  // Prints 0.
}


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au




--- Comment #1 from Don <clugdbug@yahoo.com.au>  2009-08-04 02:22:05 PDT ---
I think this is invalid.
Bar bar=1; is a construction, not an assignment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, patch
            Version|2.025                       |1.040
            Summary|Declaring struct, assigning |Struct initialisation
                   |rvalue via opAssign in same |silently inserts deadly
                   |statement fails silently    |casts




--- Comment #2 from Don <clugdbug@yahoo.com.au>  2009-08-07 01:16:33 PDT ---
Actually there is a bug:
Bar bar = 1;
should not be accepted.

Here's a really frightening case:

struct A { char [] a; }
struct B { long x; }

void main() {
   B s;
   A q = s;
}
--------------
The cause is in VarDeclaration::semantic in declaration.c, line 1083 (DMD 2.031), in the section dealing with initialisation of a struct. The code is:

            if (!ei->exp->implicitConvTo(type))
            {    Type *ti = ei->exp->type->toBasetype();
            // Don't cast away invariant or mutability in initializer
            if (!(ti->ty == Tstruct && t->toDsymbol(sc) == ti->toDsymbol(sc)))
{
                ei->exp = new CastExp(loc, ei->exp, type);
            }
            }

and in D1, it's just (line 1074):
    if (!ei->exp->implicitConvTo(type))
    ei->exp = new CastExp(loc, ei->exp, type);

If it can't be implicitly converted to a struct, why the heck should an
explicit cast be inserted???
PATCH(D1): Delete those 2 lines.
On D2, we need the same logic as for assignment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702





--- Comment #3 from Don <clugdbug@yahoo.com.au>  2009-08-08 22:19:09 PDT ---
I have confirmed that after completely removing that section of code, the DMD test suite still passes all tests. I tried to construct a valid case which required that code, but was unable to find one -- it looks as though that code is ONLY creating bugs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hskwk@inter7.jp


--- Comment #4 from Don <clugdbug@yahoo.com.au> 2009-09-07 01:16:45 PDT ---
*** Issue 3259 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


--- Comment #5 from Don <clugdbug@yahoo.com.au> 2009-09-24 06:40:24 PDT ---
There must have been something wrong with the way I tested this. It fails one of the test suite tests. Not yet patched.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702



--- Comment #6 from Don <clugdbug@yahoo.com.au> 2009-09-24 07:02:06 PDT ---
Hmm. It seems that code I commented out is used to invoke static opCall(). That seems very wrong to me, as it's allowing all sorts of other garbage to compile.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #7 from Don <clugdbug@yahoo.com.au> 2009-09-25 01:06:47 PDT ---
Here's a revised patch, same place (VarDeclaration::semantic in declaration.c, around line 1083). Replace the existing code with this version, which explicitly allows opCall and NOTHING ELSE:
---
            // Dynamic initialization uses static opCall.
            if (!ei->exp->implicitConvTo(type))
            {    // Look for opCall
            if (search_function(sd, Id::call))
                {   // Rewrite as e1.call(arguments)
                Expression * eCall = new DotIdExp(loc, e1, Id::call);
                ei->exp = new CallExp(loc, eCall, ei->exp);
            }
            }
---
This passes everything in the DMD test suite, except for one line in one test (xtest46.d, test30) which I believe to be broken. I don't think that all of the opDot() and 'alias this' possibilities are tested in the test suite, however.

Here's a tiny test which concisely tests the main features:

struct A { char [] a; }
struct B { long x; }
struct C { int a;
    static C opCall(int b) { C q; q.a=b; return q; }
}
static assert(!is(typeof( (){ A s; B q = s; })));
static assert(!is(typeof( (){ B x =1L; })));
static assert(is(typeof( (){ C g = 7; })));
static assert(is(typeof( (){ C g = 7; C h = g;})));

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2702


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> 2009-10-06 02:15:10 PDT ---
Fixed dmd 1.048 and 2.033

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------