Bug 2702 – Struct initialisation silently inserts deadly casts

Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2009-03-01T19:37:00Z
Last change time
2014-03-01T00:36:16Z
Keywords
accepts-invalid, patch, wrong-code
Assigned to
nobody
Creator
dsimcha

Comments

Comment #0 by dsimcha — 2009-03-01T19:37:49Z
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. }
Comment #1 by clugdbug — 2009-08-04T02:22:05Z
I think this is invalid. Bar bar=1; is a construction, not an assignment.
Comment #2 by clugdbug — 2009-08-07T01:16:33Z
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.
Comment #3 by clugdbug — 2009-08-08T22:19:09Z
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.
Comment #4 by clugdbug — 2009-09-07T01:16:45Z
*** Issue 3259 has been marked as a duplicate of this issue. ***
Comment #5 by clugdbug — 2009-09-24T06:40:24Z
There must have been something wrong with the way I tested this. It fails one of the test suite tests. Not yet patched.
Comment #6 by clugdbug — 2009-09-24T07:02:06Z
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.
Comment #7 by clugdbug — 2009-09-25T01:06:47Z
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;})));
Comment #8 by bugzilla — 2009-10-06T02:15:10Z
Fixed dmd 1.048 and 2.033