www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2702] New: Declaring struct, assigning rvalue via opAssign in same statement fails silently

reply d-bugmail puremagic.com writes:
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.
}


-- 
Mar 01 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug yahoo.com.au> changed:

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





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: -------
Aug 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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





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: -------
Aug 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702






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: -------
Aug 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug yahoo.com.au> changed:

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



*** 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: -------
Sep 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Sep 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702




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: -------
Sep 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2702


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Sep 25 2009
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Oct 06 2009