[Issue 3270] pure functions returning struct
http://d.puremagic.com/issues/show_bug.cgi?id=3270 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2009-12-30 17:38:24 PST --- Changeset 323 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright 2009-12-30 17:07:16 PST --- Changeset 322 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3198] wrong initializer for structs arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3198 --- Comment #2 from Don 2009-12-30 14:56:32 PST --- Or else, create a new version of TypeStruct::toDtElem, which doesn't have the special-case for structs members, and call it from StructDeclaration::toDt() and ClassDeclaration::toDt2() -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3198] wrong initializer for structs arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3198 Don changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-12-30 14:35:46 PST --- The bug clearly lies in todt.c, inside dt_t **TypeSArray::toDtElem(dt_t **pdt, Expression *e). If it's an array of structs, (ie, tbn->ty == Tstruct), then the 'e' value is completely ignored!! This is certainly wrong. Changing the two places where the check is: if (tbn->ty == Tstruct) into: if (tbn != e->type && tbn->ty == Tstruct) allows the test case to pass. But that may not be the correct criterion to use. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3270] pure functions returning struct
http://d.puremagic.com/issues/show_bug.cgi?id=3270 Don changed: What|Removed |Added Keywords||patch --- Comment #2 from Don 2009-12-30 13:11:55 PST --- Shouldn't be doing no-side-effect calls if there's a hidden parameter. This happens if the value is being returned on the stack. PATCH (e2ir.c line 287): else if (ep) -e = el_bin((tf->ispure && tf->isnothrow) ? OPcallns : OPcall,tyret,ec,ep); +e = el_bin((tf->ispure && tf->isnothrow && (retmethod != RETstack)) ? OPcallns : OPcall,tyret,ec,ep); else -e = el_una((tf->ispure && tf->isnothrow) ? OPucallns : OPucall,tyret,ec); +e = el_una((tf->ispure && tf->isnothrow && (retmethod != RETstack)) ? OPucallns : OPucall,tyret,ec); --- TEST CASE: struct Foo { int x, y; real z; } pure nothrow Foo makeFoo(const int x, const int y) { return Foo(x, y, 3.0); } void main() { auto f = makeFoo(1, 2); assert(f.x==1); assert(f.y==2); assert(f.z==3); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583 Don changed: What|Removed |Added Keywords||patch --- Comment #3 from Don 2009-12-30 12:06:31 PST --- Root cause: A bad refactoring that dropped the conversion to unsigned. PATCH: e2ir.c, line 3008 and 3113 UshrExp::toElem() and UshrAssignExp::toElem() Copy the code from D1. elem *UshrAssignExp::toElem(IRState *irs) { -return toElemBin(irs, OPshrass); +elem *eleft = e1->toElem(irs); +eleft->Ety = touns(eleft->Ety); +elem *eright = e2->toElem(irs); +elem *e = el_bin(OPshrass, type->totym(), eleft, eright); +el_setLoc(e, loc); +return e; } elem *UshrExp::toElem(IRState *irs) { -return toElemBin(irs, OPshr); +elem *eleft = e1->toElem(irs); +eleft->Ety = touns(eleft->Ety); +elem *eright = e2->toElem(irs); +elem *e = el_bin(OPshr, type->totym(), eleft, eright); +el_setLoc(e, loc); +return e; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|future |2.036 Summary|Unsigned right shift works |Regression(DMD2.037): |the same as signed right|Unsigned right shift works |shift. |the same as signed right ||shift. --- Comment #2 from Don 2009-12-30 11:26:03 PST --- Doesn't seem to happen on DMD1. Code works on DMD1.054beta. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3659] Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659 Richard Webb changed: What|Removed |Added CC||we...@beardmouse.org.uk --- Comment #1 from Richard Webb 2009-12-30 09:42:14 PST --- Same as #3607 ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3659] New: Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659 Summary: Too much exegesis on opEquals Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: and...@metalanguage.com --- Comment #0 from Andrei Alexandrescu 2009-12-30 09:14:06 PST --- struct A { bool opEquals(int x) { return false; } } Compiler says: Error: function test.A.opEquals type signature should be const bool(ref const(A)) not bool(int x) The compiler should accept any signature for opEquals. All it needs to do is rewrite a == b into a.opEquals(b) or b.opEquals(a). For classes I'm doubtful that opEquals needs to be const. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 Braxton changed: What|Removed |Added CC||d-issue-trac...@braxtech.co ||m Severity|normal |major -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] New: Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 Summary: Crashing on vector operations Product: D Version: unspecified Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d-issue-trac...@braxtech.com --- Comment #0 from Braxton 2009-12-30 08:21:09 PST --- Created an attachment (id=538) Reduction Overview: Vector operations using the concise notation (i.e. array[] += 0.5f) are crashing under DMD 2.037 running on Mac OS X 10.6.2. When these operations are replaced with a corresponding foreach loop of the same functionality, the crash does not occur. Steps to Reproduce: 1) Download the attached reduction 2) Build and run with DMD 2.037 under Mac OS X 10.6.2 Actual Results: The application crashed with the attached crash log. Expected Results: The application should return successfully. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 --- Comment #1 from Braxton 2009-12-30 08:21:42 PST --- Created an attachment (id=539) Crash Log -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3442] scope(exit) Problem
http://d.puremagic.com/issues/show_bug.cgi?id=3442 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Don 2009-12-29 22:12:51 PST --- I'm closing this as invalid since it has no test case. But it is probably a duplicate of one of the bugs I mentioned. Reopen if you have a complete test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 400] forward reference error; no propety X for type Y (struct within struct)
http://d.puremagic.com/issues/show_bug.cgi?id=400 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella 2009-12-29 19:17:26 PST --- http://www.dsource.org/projects/dmd/changeset/319 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3138] Const bug
http://d.puremagic.com/issues/show_bug.cgi?id=3138 Stewart Gordon changed: What|Removed |Added Keywords|accepts-invalid |ice-on-invalid-code CC||s...@iname.com --- Comment #3 from Stewart Gordon 2009-12-29 13:44:03 PST --- It may've been fixed now, but still, how is this accepts-invalid? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 400] forward reference error; no propety X for type Y (struct within struct)
http://d.puremagic.com/issues/show_bug.cgi?id=400 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2009-12-29 16:12:09 PST --- Changeset 319 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3569] DMD Stack Overflow with a struct member function inside a C-style struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3569 Don changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au --- Comment #2 from Don 2009-12-29 12:32:09 PST --- This patch to AssertExp::interpret() prevents the stack overflow, turning it into a simple error message. It doesn't patch the regression. As Rob notes, the static struct initializers are evaluated at compile time, but they shouldn't be. Nonetheless, this patch is still required to prevent segfaults in the case where they are forcibly evaluated at compile time. Eg, code like the following: struct Foo { Foo bar() { return this; } } struct Bar { Foo foo; int fog() { enum Bar r = { foo.bar() }; return 3; } } PATCH --- Index: interpret.c === --- interpret.c(revision 318) +++ interpret.c(working copy) @@ -2535,14 +2535,18 @@ if( this->e1->op == TOKaddress) { // Special case: deal with compiler-inserted assert(&this, "null this") AddrExp *ade = (AddrExp *)this->e1; -if(ade->e1->op == TOKthis && istate->localThis) -return istate->localThis->interpret(istate); +if(ade->e1->op == TOKthis && istate->localThis) +if (istate->localThis->op==TOKdotvar + && ((DotVarExp *)(istate->localThis))->e1->op==TOKthis) +return getVarExp(loc, istate, ((DotVarExp *)(istate->localThis))->var); +else +return istate->localThis->interpret(istate); } -if (this->e1->op == TOKthis) -{ +if (this->e1->op == TOKthis) +{ if(istate->localThis) -return istate->localThis->interpret(istate); -} +return istate->localThis->interpret(istate); +} e1 = this->e1->interpret(istate); if (e1 == EXP_CANT_INTERPRET) goto Lcant; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3575] CTFE: member structs not initialized correctly
http://d.puremagic.com/issues/show_bug.cgi?id=3575 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2009-12-30 00:11:37 PST --- Changeset 321 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 --- Comment #6 from Leandro Lucarella 2009-12-29 09:02:56 PST --- (In reply to comment #5) > http://d.puremagic.com/issues/show_bug.cgi?id=282 Damn! http://www.dsource.org/projects/dmd/changeset/318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3611] Enum forward referencing regression
http://d.puremagic.com/issues/show_bug.cgi?id=3611 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella 2009-12-29 08:58:36 PST --- http://www.dsource.org/projects/dmd/changeset/317 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3628] can't cast null to int
http://d.puremagic.com/issues/show_bug.cgi?id=3628 --- Comment #3 from Leandro Lucarella 2009-12-29 08:58:06 PST --- http://www.dsource.org/projects/dmd/changeset/316 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #5 from Leandro Lucarella 2009-12-29 09:02:30 PST --- http://d.puremagic.com/issues/show_bug.cgi?id=282 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 102] Forward reference nested class wheel.
http://d.puremagic.com/issues/show_bug.cgi?id=102 Rainer Schuetze changed: What|Removed |Added Attachment #459 is|0 |1 obsolete|| --- Comment #12 from Rainer Schuetze 2009-12-29 06:52:41 PST --- Created an attachment (id=537) updated patch again This is another update with the proposed addition and 2 little extensions: - when a struct is searched for identifiers, and its semantic analysis is deferred, try the semantic analysis again. This is already done for classes and is simply extended to structs. - retrying deferred analysis is only done when any "progress" has been made (i.e. new classes or structs have been analysed). This reduces the performance and memory penalties caused by the deferral mechanism. This patch is necessary to compile QtD with DMD 2.037. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #13 from Leandro Lucarella 2009-12-29 08:47:27 PST --- http://www.dsource.org/projects/dmd/changeset/314 http://www.dsource.org/projects/dmd/changeset/315 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3628] can't cast null to int
http://d.puremagic.com/issues/show_bug.cgi?id=3628 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella 2009-12-29 08:56:03 PST --- http://www.dsource.org/projects/dmd/changeset/316 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3600] template instantiation with empty tuple
http://d.puremagic.com/issues/show_bug.cgi?id=3600 Rainer Schuetze changed: What|Removed |Added Keywords||patch CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze 2009-12-29 04:12:05 PST --- I don't know why this worked before and could not see a change that caused the regression from version 2.036, but here is a patch that adds an empty type tuple to the deduced template parameters if it has not yet been created and does not show up in the function parameters: Index: template.c === --- template.c(revision 317) +++ template.c(working copy) @@ -1142,6 +1142,13 @@ /* Fill in any missing arguments with their defaults. */ +if(tp && fptupindex < 0 && nargsi == dedargs->dim - 1) +{ // for variadic type parameters not in function parameters, allow empty tuple +Tuple *t = new Tuple(); +dedargs->data[dedargs->dim - 1] = (void *)t; +nargsi++; +} + for (i = nargsi; i < dedargs->dim; i++) { TemplateParameter *tp = (TemplateParameter *)parameters->data[i]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3600] template instantiation with empty tuple
http://d.puremagic.com/issues/show_bug.cgi?id=3600 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|major |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3491] typeof( (string[string]).init)) == AssociativeArray!(string, string), doesn't implicitly convert to string[string].
http://d.puremagic.com/issues/show_bug.cgi?id=3491 Rainer Schuetze changed: What|Removed |Added Keywords||patch, rejects-valid CC||r.sagita...@gmx.de Severity|normal |regression --- Comment #1 from Rainer Schuetze 2009-12-29 03:47:45 PST --- A much simpler version also fails: void main() { int[int] s; s = s.init; } c:\l\dmd-2.036\windows\bin\..\..\src\druntime\import\object.di(294): Error: cann ot implicitly convert expression (_D6object26__T16AssociativeArrayTiTiZ16Associa tiveArray6__initZ) of type AssociativeArray!(int,int) to int[int] This used to work for DMD 2.035, so it is a regression. There seems to be some inconsistency whether to use the new implementation of associative arrays or the original type. The following patch ensures usage of the library type for implicitely casting. Index: mtype.c === --- mtype.c(revision 317) +++ mtype.c(working copy) @@ -6761,6 +6761,9 @@ { MATCH m; //printf("TypeStruct::implicitConvTo(%s => %s)\n", toChars(), to->toChars()); +if(to->ty == Taarray) +to = ((TypeAArray*)to)->getImpl()->type; + if (ty == to->ty && sym == ((TypeStruct *)to)->sym) {m = MATCHexact;// exact match if (mod != to->mod) Index: e2ir.c === --- e2ir.c(revision 317) +++ e2ir.c(working copy) @@ -3508,6 +3508,12 @@ elem *e = e1->toElem(irs); Type *tfrom = e1->type->toBasetype(); Type *t = to->toBasetype();// skip over typedef's + +if(tfrom->ty == Taarray) +tfrom = ((TypeAArray*)tfrom)->getImpl()->type; +if(t->ty == Taarray) +t = ((TypeAArray*)t)->getImpl()->type; + if (t->equals(tfrom)) goto Lret; This causes some strange cast (pointer to AA - is this supposed to work?) in object.d to fail, but I could not find the place where this magic happens. So I changed the definition : Index: object.di === --- object.di(revision 222) +++ object.di(working copy) @@ -300,5 +300,7 @@ Value[Key] rehash() @property { -return cast(Value[Key]) _aaRehash(&p, typeid(Value[Key])); +Value[Key] aa; +aa.p = _aaRehash(&p, typeid(Value[Key])); +return aa; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 --- Comment #12 from Walter Bright 2009-12-29 03:08:36 PST --- (In reply to comment #11) > Changeset 318 Wrong changeset, oops! 318 is for bugzilla 282 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright 2009-12-29 03:07:49 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1160] enums can not be forward referenced
http://d.puremagic.com/issues/show_bug.cgi?id=1160 --- Comment #3 from Walter Bright 2009-12-29 03:19:59 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #11 from Walter Bright 2009-12-29 03:04:14 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3657] No lexical scope for local variables in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=3657 Rainer Schuetze changed: What|Removed |Added Keywords||patch Priority|P2 |P3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3552] ICE(mtype.c): declaring a variable called 'AssociativeArray' then using an AA.
http://d.puremagic.com/issues/show_bug.cgi?id=3552 Don changed: What|Removed |Added Keywords||patch --- Comment #4 from Don 2009-12-29 00:58:15 PST --- PATCH: Instead of trying to instantiate AssociativeArray, do .AssociativeArray instead. Index: mtype.c === --- mtype.c(revision 317) +++ mtype.c(working copy) @@ -3854,13 +3854,14 @@ * But the instantiation can fail if it is a template specialization field * which has Tident's instead of real types. */ -TemplateInstance *ti = new TemplateInstance(loc, Id::AssociativeArray); + Objects *tiargs = new Objects(); tiargs->push(index); tiargs->push(next); -ti->tiargs = tiargs; +DotTemplateInstanceExp *dti = new DotTemplateInstanceExp(loc, new IdentifierExp(loc, Id::empty), Id::AssociativeArray, tiargs); -ti->semantic(sc); +dti->semantic(sc); +TemplateInstance *ti = dti->ti; ti->semantic2(sc); ti->semantic3(sc); impl = ti->toAlias()->isStructDeclaration(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3657] New: No lexical scope for local variables in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=3657 Summary: No lexical scope for local variables in debug info Product: D Version: unspecified Platform: Other OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: r.sagita...@gmx.de --- Comment #0 from Rainer Schuetze 2009-12-29 02:47:59 PST --- Consider import std.stdio; void main() { for(int i = 0; i < 10; i++) writefln("1 - %d", i); for(int i = 0; i < 10; i++) writefln("2 - %d", i); } This declares two different variables "i", but the debugger only shows the value of the first variable, even while stepping through the second loop. (The list of local variables does show two variables "i".) This is caused by DMD not emitting any life time info of local variables. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3657] No lexical scope for local variables in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=3657 --- Comment #1 from Rainer Schuetze 2009-12-29 02:57:56 PST --- Created an attachment (id=536) add lexical scope to local symbols in codeview debug info The patch consists of two parts: 1. modify the parser to remember the end of scope statements. 2. transfer the life-time info to the debug info. The latter is straight forward, but the second part is a bit complicated. As scoping information is lost in the code generation, only the line of declaration and the end of the enclosing scope is remembered by the symbol. The life-time of the variable in terms of code byte offset and length is then reconstructed from the line number info. This is only implemented for CodeView information, as I don't know anything about the other formats. Another complication: optlink removes the corresponding debug entries, so I had to use pseudo-symbols to get this info to cv2pdb and convert them back there. This might confuse other tools, so maybe this feature should be enabled by some command line switch only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1330] Array slicing does not work the same way in CTFE as at runtime
http://d.puremagic.com/issues/show_bug.cgi?id=1330 Don changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from Don 2009-12-29 00:12:38 PST --- *** Issue 3456 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: ---
[Issue 3456] ref foreach over array in CTFE silently fails.
http://d.puremagic.com/issues/show_bug.cgi?id=3456 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #2 from Don 2009-12-29 00:12:38 PST --- *** This issue has been marked as a duplicate of issue 1330 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3615] returning .idup of local static array doesn't work in ctfe
http://d.puremagic.com/issues/show_bug.cgi?id=3615 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-12-28 22:59:06 PST --- This is fixed in DMD2 svn 317 or earlier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3642] Poor error message: function ___ not callable with argument types ___
http://d.puremagic.com/issues/show_bug.cgi?id=3642 Jason House changed: What|Removed |Added Summary|Poor error message when |Poor error message: |using shared: function ___ |function ___ not callable |not callable with argument |with argument types ___ |types ___ | --- Comment #3 from Jason House 2009-12-28 21:02:22 PST --- I just came across another example where this is poor. No test case this time ;) Here's the error message: hb/search/factory.d(58): Error: function libego.adapter.move.compressedHash () is not callable using argument types () Any guesses what is wrong? Calling a no argument function is not callable using no arguments? In this particular case, the instance of libego.adapter.move is immutable and the compressedHash function is neither marked as const nor immuatable. The error message really should be better. Example alternate error message: hb/search/factory.d(58): Error: Can't call mutating function on an immutable object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3611] Enum forward referencing regression
http://d.puremagic.com/issues/show_bug.cgi?id=3611 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2009-12-28 21:10:00 PST --- Changeset 317 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3656] delegate should specify 'this' decorations
http://d.puremagic.com/issues/show_bug.cgi?id=3656 --- Comment #1 from Steven Schveighoffer 2009-12-28 08:45:23 PST --- Note that more important than const decoration propogation is shared propogation, since the compiler should call the delegate differently. Note also that with contravariance for delegates as identified in bug 3075 would make this a lot easier to deal with. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #3 from Walter Bright 2009-12-28 21:14:32 PST --- The compiler is working as designed. The final function is not virtual, so it is never needed in the vtbl[]. Hence, there is no undefined reference to it in the vtbl[]. The non-final function is virtual, and so a reference to it is put into the vtbl[]. The function's implementation must exist somewhere, and if it did, the linker would put a reference to the implementation in the vtbl[]. This feature allows one to have an implementation that is hidden from the user of the class. If you truly do not want to implement the function, declare it as 'abstract'. Then, a NULL is put in the corresponding place in the vtbl[]. Not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3075] void delegate(const(void)[]) should be implicitly convertable to void delegate(void[])
http://d.puremagic.com/issues/show_bug.cgi?id=3075 --- Comment #21 from Steven Schveighoffer 2009-12-28 08:41:46 PST --- Just submitted bug 3656, which might require contravariance for delegates to make it work properly... Consider that a function foo: foo(void delegate() dg) { dg(); } should compile with the following: class A { void f1() const {} void f2() {} } void main() { A a = new A; foo(&a.f1); foo(&a.f2); } But if bug 3656 is resolved (and it must be to preserve const), then there is no current way to mark foo as not caring whether the delegate is const or not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 --- Comment #2 from Eldar Insafutdinov 2009-12-27 05:03:55 PST --- Ok, actually I am wrong here, final methods are not optimized away - they just don't exist. And if nobody uses them - you are safe. But the similar behavior should be present for virtual functions as well I believe - virtual function without a body should not be present in vtable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] New: Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 Summary: Virtual functions without bodies are not optimized away. Product: D Version: 2.035 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: e.insafutdi...@gmail.com --- Comment #0 from Eldar Insafutdinov 2009-12-27 04:12:27 PST --- This is compiled fine, as final method without a body is optimized away: class Boo { final void foo(); } However this does not: class Boo { void foo(); } linker fails with: main.o:(.rodata+0x194): undefined reference to `_D4main3Boo3fooMFZv' This might be because function is put into vtable. Is it easy to fix? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 --- Comment #1 from Eldar Insafutdinov 2009-12-27 04:13:25 PST --- (In reply to comment #0) > This is compiled fine, as final method without a body is optimized away: > > class Boo > { > final void foo(); > } > Of course it is optimized away if it is not used. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3656] New: delegate should specify 'this' decorations
http://d.puremagic.com/issues/show_bug.cgi?id=3656 Summary: delegate should specify 'this' decorations Product: D Version: 2.036 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: schvei...@yahoo.com --- Comment #0 from Steven Schveighoffer 2009-12-28 06:34:17 PST --- Note, this bug applies to 2.037, but for some reason it's not in the version list. import std.stdio; class A { void f() {} } void main() { const A a = new A; auto g = &a.f; writefln("%s", typeof(g).stringof); g(); } This outputs: void delegate() First, the line: auto g = &a.f; shouldn't compile because f cannot be called on a. However, even if f is changed to a const function, the output is still "void delegate()", it should be "void delegate() const". This breaks const correctness without a cast, because I can call g, but not a.f. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3654] New: auto return doesn't work for nested functions
http://d.puremagic.com/issues/show_bug.cgi?id=3654 Summary: auto return doesn't work for nested functions Product: D Version: 2.036 Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bary...@smp.if.uj.edu.pl --- Comment #0 from Witold Baryluk 2009-12-26 18:55:31 PST --- Title says it all, example: module aaa; void foo() { auto bar() { return 1; } } $ dmd2.037 -c aaa.d aaa.d(2): no identifier for declarator bar aaa.d(2): semicolon expected, not '{' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2876] Enhancement to 'auto' return
http://d.puremagic.com/issues/show_bug.cgi?id=2876 Witold Baryluk changed: What|Removed |Added Status|NEW |RESOLVED CC||bary...@smp.if.uj.edu.pl Resolution||WORKSFORME --- Comment #4 from Witold Baryluk 2009-12-26 18:52:06 PST --- I don't see any problem with this example. It is quite simple to compile, and in fact it works in DMD 2.037 as desired. This example uses three things which are fully supported: - static if over template parameters, no problem for long time - coping/allocating variable on heap if they are used in delegate (or nested functions) and returned from function (escaping scope), no problem in most cases - infering return type, no problem as we have exactly one return (after static if selection), and its type is quite "simple" (it is delegate int(int), or delegate float(float)), and compiler knows this. Please close this bug with WORKSFORME. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3643] Compiler error on obtaining typeid of a property
http://d.puremagic.com/issues/show_bug.cgi?id=3643 --- Comment #2 from Phil Deets 2009-12-26 16:50:47 PST --- The documentation says the argument can be a type or an expression. http://www.digitalmars.com/d/2.0/expression.html#TypeidExpression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3653] Problem sorting array of Rebindable
http://d.puremagic.com/issues/show_bug.cgi?id=3653 --- Comment #1 from pc 2009-12-26 15:14:42 PST --- (From update of attachment 535) Note: to make this compile without the hack in the attached file, one would have to import std.typecons as well as commenting out the sort line.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] New: Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652 Summary: Allow implicit casting of dynamic array slices of known size to static array Product: D Version: 2.036 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bary...@smp.if.uj.edu.pl --- Comment #0 from Witold Baryluk 2009-12-26 14:17:17 PST --- Consider this: void foo(float[4] x) { return x[0]+x[1]*x[2]-x[3]; } void main() { float[] xs = read_floats_from_file(); foreach (i; 0 .. xs.length-4) { foo(xs[ i .. i+4]); } } or simpler thing to calculate in compile time: void main() { float[] xs = read_floats_from_file(); foo(xs[ 0 .. 4]); } In both cases compiler will say: cannot implicitly convert expression (_adDupT((& _D11TypeInfo_Af6__initZ),qs[0u..4u])) of type float[] to float[4u] or something similar. It is hard to see why this is really needed. How about allowing (and performing) implicit cast to static array if compiler knows (or can easly infere) size of the slice and it aggree with target type? Of course there will be situations where we have no knowledge about it: void main() { float[] xs = read_floats_from_file(); uint a = rand() % xs.length; foo(xs[ 0 .. a ]); } But allowing implicit cast also can detect other errors: foreach (i; 0 .. xs.length-4) { foo(xs[ i .. i+3]); } Compiler in such situation will complain not because we are using float[] to float[4] conversion, but because we are trying to call float[4] function using float[3] slice. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3653] New: Problem sorting array of Rebindable
http://d.puremagic.com/issues/show_bug.cgi?id=3653 Summary: Problem sorting array of Rebindable Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: peng2che...@yahoo.com --- Comment #0 from pc 2009-12-26 15:11:02 PST --- Created an attachment (id=535) short test of arrays of Rebindable Digital Mars D Compiler v2.037 /* The following did not compile. Error deep in phobos due to the line starting with "sort". (comment it out, and no problem). */ import std.traits; import std.stdio, std.algorithm; class C1 { int x; this(int x){this.x = x;} int y() const { return x; } } alias Rebindable!(const(C1)) RC1; void test3() { RC1[] aCs; aCs.length = 2; aCs[0] = new C1(9); aCs[1] = new C1(10); aCs ~= RC1(new C1(8)); sort!("a.x < b.x")(aCs); //compiles only after hack (see attached file) foreach(ac; aCs) writeln(ac.y()); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652 --- Comment #2 from Witold Baryluk 2009-12-26 14:21:40 PST --- It is even worse that i was innitially thinking: explicit casting doesn't work: series2.d(113): Error: e2ir: cannot cast qs[0u..1u] of type float[] to type float[1u] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3646] Default values of function arguments are ignored when instantiating a template.
http://d.puremagic.com/issues/show_bug.cgi?id=3646 --- Comment #2 from Eldar Insafutdinov 2009-12-26 12:51:57 PST --- (In reply to comment #1) > This is a bit more tricky than it looks like. > > The question here is, how many times should foo be instanciated? > DMD answers "just 1 time", and I agree with it, since bar and bam have same > signature and mangling. > But this only happens if foo!(bar) is instanciated before foo!(bam), because > when templates are instantiates on first use. When you instanciate foo!(bam) > first, it doesn't get rewritten and therefore fails to compile. > > I guess the only fix for this issue would be to create an implicit trampoline > to invoke functions with default arguments, but only Walter can say for sure. Yeah, that was pretty much what I was thinking about. The issue cuts down to a question, should Foo be instantiated once or are the function types equal? For binary size and efficiency purposes I agree that there should be one instantiation. On the other hand for meta programming and code generation which is what I am doing I would like to have them as separate types, as I don't want to loose this information. Walter or Andrei would probably have to comment on this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652 --- Comment #1 from Witold Baryluk 2009-12-26 14:18:34 PST --- So essentially problem is that slices are just dynamic arrays. So bringing back the topic of making slices different/distinctive types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3651] New: mangleof broken for enums
http://d.puremagic.com/issues/show_bug.cgi?id=3651 Summary: mangleof broken for enums Product: D Version: 1.051 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2009-12-26 11:32:07 PST --- First off, this bug report is for dmd 1.053, not 1.051; but bugzilla let's me only select up to 1.051. .mangleof is broken for enums: enum foo { item, } //should output a mangled name with "foo" in it, but outputs "i" pragma(msg, foo.mangleof); void main() {} I apologize if this is a duplicate bug; there were quite a lot of enum bugs which look slightly similar (the compiler seems to reduce enums to ints prematurely in a lot of cases). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3543] : ? operator can't find common type for interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=3543 --- Comment #2 from nfx...@gmail.com 2009-12-26 10:47:29 PST --- Note how this makes array literal type inference suck in dmd 2.037: class Root { } class A : Root { } class B : Root { } bool bla; void main() { A a; B b; Root t; t = a; t = b; //works //Error: cannot implicitly convert expression (a) of type fgd.Root to fgd.B Root[] t2 = [a, b]; } If this bug gets fixed, array literal type inference in D2 will be improved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3650] New: functions are considered pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3650 Summary: functions are considered pointers Product: D Version: 1.051 Platform: Other OS/Version: All Status: NEW Keywords: wrong-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2009-12-26 09:45:34 PST --- First off, this bug report is for dmd 1.053, not 1.051; but bugzilla let's me only select up to 1.051. The following code outputs "what (void())()", which shows that function pointers are matched with is(T T2 : T2*). I think this shouldn't be the case: although technically function pointers really are pointers, D doesn't declare them using the pointer syntax, doesn't allow them to be dereferenced, and they don't point to any type. If this bug is fixed, functions won't match with is(T T2 : T2*) anymore. If this is just an anti-feature and not a bug, please mark this bug report as "invalid". struct X { void function() foo; } void moo(T)() { static if (is(T T2 : T2*)) { pragma(msg, "what "~T2.stringof); } } void main() { X x; foreach (int index, z; x.tupleof) { moo!(typeof(z)); } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3650] functions are considered pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3650 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #1 from Stewart Gordon 2009-12-26 11:11:08 PST --- I've always been under the impression that immediate function types aren't meant to exist in D, which would mean that the is expression should fail. But there does seem to be some confusion over it. And in any case, the stringof does seem wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---